[U-Boot] u-boot-socfpga repository
Hello,
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
Best regards, Marek Vasut
On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut marex@denx.de wrote:
Hello,
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes.
That would be faster and would not disturb Albert.
Best Regards Masahiro Yamada
Hi,
On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut marex@denx.de wrote:
Hello,
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes.
That would be faster and would not disturb Albert.
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. Alberts know that and it is working quite well. It is enough to talk to him and that's it. In socfpga case I think there are guys from Altera who maintain it.
Thanks, Michal
Hi Michal,
On Thu, 11 Sep 2014 06:56:04 +0200 Michal Simek monstr@monstr.eu wrote:
Hi,
On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut marex@denx.de wrote:
Hello,
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes.
That would be faster and would not disturb Albert.
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right?
It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch.
I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase.
What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs?
Alberts know that and it is working quite well. It is enough to talk to him and that's it. In socfpga case I think there are guys from Altera who maintain it.
Best Regards Masahiro Yamada
On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
Hi Michal,
Hi,
On Thu, 11 Sep 2014 06:56:04 +0200
Michal Simek monstr@monstr.eu wrote:
Hi,
On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
On Thu, 11 Sep 2014 01:33:20 +0200
Marek Vasut marex@denx.de wrote:
Hello,
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes.
That would be faster and would not disturb Albert.
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right?
It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch.
I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase.
What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs?
[...]
I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this.
Best regards, Marek Vasut
On 09/18/2014 09:27 AM, Marek Vasut wrote:
On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
Hi Michal,
Hi,
On Thu, 11 Sep 2014 06:56:04 +0200
Michal Simek monstr@monstr.eu wrote:
Hi,
On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
On Thu, 11 Sep 2014 01:33:20 +0200
Marek Vasut marex@denx.de wrote:
Hello,
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes.
That would be faster and would not disturb Albert.
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right?
It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch.
I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase.
What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs?
[...]
I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this.
+1 on this if Masahiro wants to have separate repo.
Thanks, Michal
On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote:
On 09/18/2014 09:27 AM, Marek Vasut wrote:
On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
Hi Michal,
Hi,
On Thu, 11 Sep 2014 06:56:04 +0200
Michal Simek monstr@monstr.eu wrote:
Hi,
On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
On Thu, 11 Sep 2014 01:33:20 +0200
Marek Vasut marex@denx.de wrote:
Hello,
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes.
That would be faster and would not disturb Albert.
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right?
It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch.
I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase.
What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs?
[...]
I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this.
+1 on this if Masahiro wants to have separate repo.
There is no repo for those SoCs at all, so I'd be all for it.
Best regards, Marek Vasut
Hi guys,
On 09/18/2014 10:02 AM, Marek Vasut wrote:
On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote:
On 09/18/2014 09:27 AM, Marek Vasut wrote:
On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
Hi Michal,
Hi,
On Thu, 11 Sep 2014 06:56:04 +0200
Michal Simek monstr@monstr.eu wrote:
Hi,
On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
On Thu, 11 Sep 2014 01:33:20 +0200
Marek Vasut marex@denx.de wrote: > Hello, > > I'd be interested in maintaining u-boot-socfpga repository. So far, > we don't have a repo for this platform and there is a large flurry > of patches flying around without any kind of central point for them. > I'd like to get your formal consent for starting this and if you > agree, I'd start sending PR to Albert once the repo is in place.
Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes.
That would be faster and would not disturb Albert.
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right?
It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch.
I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase.
What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs?
[...]
I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this.
+1 on this if Masahiro wants to have separate repo.
There is no repo for those SoCs at all, so I'd be all for it.
This is the flow which is IMHO the best.
Masahiro will send the RFC patch for MAINTAINERS file to Albert with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it that it means that he agrees with that person to be responsible for this part. Based on that Masahiro asks for repo (if he wants it) and repo will be created.
Then he sends update patch to mailing list and after review he will apply this patch to his repo and start to collect SoC specific patches and then send pull request to Albert. Also record on wiki will be updated based on that.
This seems to me like a sensible way how to do it which is transparent for everybody.
The same for Masahiro regarding Kconfig if Tom agrees with it.
Thanks, Michal
Hi Michal,
On Thu, 18 Sep 2014 10:24:39 +0200 Michal Simek monstr@monstr.eu wrote:
Hi guys,
On 09/18/2014 10:02 AM, Marek Vasut wrote:
On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote:
On 09/18/2014 09:27 AM, Marek Vasut wrote:
On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
Hi Michal,
Hi,
On Thu, 11 Sep 2014 06:56:04 +0200
Michal Simek monstr@monstr.eu wrote:
Hi,
On 09/11/2014 05:09 AM, Masahiro Yamada wrote: > On Thu, 11 Sep 2014 01:33:20 +0200 > > Marek Vasut marex@denx.de wrote: >> Hello, >> >> I'd be interested in maintaining u-boot-socfpga repository. So far, >> we don't have a repo for this platform and there is a large flurry >> of patches flying around without any kind of central point for them. >> I'd like to get your formal consent for starting this and if you >> agree, I'd start sending PR to Albert once the repo is in place. > > Me too. I'd like to own u-boot-uniphier to collect > Panasonic-SoC-specific changes. > > That would be faster and would not disturb Albert.
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right?
It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch.
I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase.
What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs?
[...]
I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this.
+1 on this if Masahiro wants to have separate repo.
There is no repo for those SoCs at all, so I'd be all for it.
This is the flow which is IMHO the best.
Thanks for your suggestion!
Masahiro will send the RFC patch for MAINTAINERS file to Albert with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it that it means that he agrees with that person to be responsible for this part. Based on that Masahiro asks for repo (if he wants it) and repo will be created.
The patch for MAINTAINERS is already on our patchwork. Is this the one you mentioned? http://patchwork.ozlabs.org/patch/386108/
If so, all I have to do now is to just wait until Albert ackes it?
Best Regards Masahiro Yamada
Hi Masahiro,
On Thu, 18 Sep 2014 19:13:04 +0900, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Michal,
On Thu, 18 Sep 2014 10:24:39 +0200 Michal Simek monstr@monstr.eu wrote:
Hi guys,
On 09/18/2014 10:02 AM, Marek Vasut wrote:
On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote:
On 09/18/2014 09:27 AM, Marek Vasut wrote:
On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote:
Hi Michal,
Hi,
On Thu, 11 Sep 2014 06:56:04 +0200
Michal Simek monstr@monstr.eu wrote: > Hi, > > On 09/11/2014 05:09 AM, Masahiro Yamada wrote: >> On Thu, 11 Sep 2014 01:33:20 +0200 >> >> Marek Vasut marex@denx.de wrote: >>> Hello, >>> >>> I'd be interested in maintaining u-boot-socfpga repository. So far, >>> we don't have a repo for this platform and there is a large flurry >>> of patches flying around without any kind of central point for them. >>> I'd like to get your formal consent for starting this and if you >>> agree, I'd start sending PR to Albert once the repo is in place. >> >> Me too. I'd like to own u-boot-uniphier to collect >> Panasonic-SoC-specific changes. >> >> That would be faster and would not disturb Albert. > > I am not sure if you need to have separate repo to work like this. > I am keeping zynq patches in my microblaze repo and sending pull > request to Albert (or Tom now) and there is no problem with that.
The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right?
It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch.
I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase.
What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs?
[...]
I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this.
+1 on this if Masahiro wants to have separate repo.
There is no repo for those SoCs at all, so I'd be all for it.
This is the flow which is IMHO the best.
Thanks for your suggestion!
Masahiro will send the RFC patch for MAINTAINERS file to Albert with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it that it means that he agrees with that person to be responsible for this part. Based on that Masahiro asks for repo (if he wants it) and repo will be created.
The patch for MAINTAINERS is already on our patchwork. Is this the one you mentioned? http://patchwork.ozlabs.org/patch/386108/
If so, all I have to do now is to just wait until Albert ackes it?
Your wait is over. :)
I assume you're going to re-delegate the uniphier series to yourself once this is done? Or do you want me to apply it?
Best Regards Masahiro Yamada
Amicalement,
Hi Albert,
2014-09-18 20:44 GMT+09:00 Albert ARIBAUD albert.u.boot@aribaud.net:
Hi Masahiro,
On Thu, 18 Sep 2014 19:13:04 +0900, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Michal,
On Thu, 18 Sep 2014 10:24:39 +0200 Michal Simek monstr@monstr.eu wrote:
Hi guys,
On 09/18/2014 10:02 AM, Marek Vasut wrote:
On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote:
On 09/18/2014 09:27 AM, Marek Vasut wrote:
On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote: > Hi Michal,
Hi,
> On Thu, 11 Sep 2014 06:56:04 +0200 > > Michal Simek monstr@monstr.eu wrote: >> Hi, >> >> On 09/11/2014 05:09 AM, Masahiro Yamada wrote: >>> On Thu, 11 Sep 2014 01:33:20 +0200 >>> >>> Marek Vasut marex@denx.de wrote: >>>> Hello, >>>> >>>> I'd be interested in maintaining u-boot-socfpga repository. So far, >>>> we don't have a repo for this platform and there is a large flurry >>>> of patches flying around without any kind of central point for them. >>>> I'd like to get your formal consent for starting this and if you >>>> agree, I'd start sending PR to Albert once the repo is in place. >>> >>> Me too. I'd like to own u-boot-uniphier to collect >>> Panasonic-SoC-specific changes. >>> >>> That would be faster and would not disturb Albert. >> >> I am not sure if you need to have separate repo to work like this. >> I am keeping zynq patches in my microblaze repo and sending pull >> request to Albert (or Tom now) and there is no problem with that. > > The point is that you collect Zynq-specific patches in your own place by > yourself and then send a pull-req to Albert or Tom, right? > > It does not matter whether it is a separate u-boot-zynq repo or > u-boot-microbraze/zynq branch. > > > I have sent the first series to add the core support of Panasonic SoCs > and boards (but it is taking much longer than I have expected) > and then I am planning to send more features and boards in the next > phase. > > > What's the difference between what I want to do for Panasonic SoCs > and what you usually do for Zynq SoCs?
[...]
I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this.
+1 on this if Masahiro wants to have separate repo.
There is no repo for those SoCs at all, so I'd be all for it.
This is the flow which is IMHO the best.
Thanks for your suggestion!
Masahiro will send the RFC patch for MAINTAINERS file to Albert with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it that it means that he agrees with that person to be responsible for this part. Based on that Masahiro asks for repo (if he wants it) and repo will be created.
The patch for MAINTAINERS is already on our patchwork. Is this the one you mentioned? http://patchwork.ozlabs.org/patch/386108/
If so, all I have to do now is to just wait until Albert ackes it?
Your wait is over. :)
Thanks!!
I assume you're going to re-delegate the uniphier series to yourself once this is done? Or do you want me to apply it?
Do not apply it, please.
I've received some comments on this version and I am planning to send v5.
I will change the state of this version to Superseded lator.
Best Regards Masahiro Yamada
Dear Tom,
In message 201409180927.35918.marex@denx.de Marek Vasut wrote:
I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this.
I did not see any negative comments for this. So is it OK to create the panasonic repo as suggested?
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Thu, 18 Sep 2014 10:32:46 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Tom,
In message 201409180927.35918.marex@denx.de Marek Vasut wrote:
I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this.
I did not see any negative comments for this. So is it OK to create the panasonic repo as suggested?
I really appreciate it!
@ Marek and Masahiro: if we reach an agreement to create such repos, please send me your SSH public keys that shall be used for these. Also, what should the names be - u-boot-socfpga ? And u-boot-uniphier ? [But is there not a chance that Pana- sonic might have other SoCs that might be mainlines? So maybe we should use u-boot-panasonic instead?]
This is a question I have not answered yet.
Wolfgang, UniPhier is kind of a brand name of system LSIs developed by Panasonic. I'd like to name u-boot-uniphier.git for some (not technical but political) reason.
Best Regards Masahiro Yamada
Dear Masahiro,
In message 20140918174315.70F0.AA925319@jp.panasonic.com you wrote:
I did not see any negative comments for this. So is it OK to create the panasonic repo as suggested?
I really appreciate it!
OK. I think Michal Simek posted a nice proposal for the actual work flow to set this up. Could you please do as he suggested?
In parallel, please send me you public SSH key (private mail).
Best regards,
Wolfgang Denk
Dear Michal,
In message 54112B64.5010104@monstr.eu you wrote:
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it.
I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information.
In socfpga case I think there are guys from Altera who maintain it.
Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this.
As far as I am concerned, I support both Marek's and Masahiro's requests.
@ Marek and Masahiro: if we reach an agreement to create such repos, please send me your SSH public keys that shall be used for these. Also, what should the names be - u-boot-socfpga ? And u-boot-uniphier ? [But is there not a chance that Pana- sonic might have other SoCs that might be mainlines? So maybe we should use u-boot-panasonic instead?]
Best regards,
Wolfgang Denk
Hi!
In socfpga case I think there are guys from Altera who maintain it.
Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this.
As far as I am concerned, I support both Marek's and Masahiro's requests.
Repository for socfpga work is a good idea, thanks.
One person I have in my email lists is Charles Manning -- he did preloader work before, I put him into cc list.
Pavel
On Thursday, September 11, 2014 at 09:55:55 AM, Pavel Machek wrote:
Hi!
In socfpga case I think there are guys from Altera who maintain it.
Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this.
As far as I am concerned, I support both Marek's and Masahiro's requests.
Repository for socfpga work is a good idea, thanks.
One person I have in my email lists is Charles Manning -- he did preloader work before, I put him into cc list.
Good idea, thanks!
Best regards, Marek Vasut
On Wed, Sep 10, 2014 at 6:33 PM, Marek Vasut marex@denx.de wrote:
Hello,
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
I maintain a linux git repo at git://git.rocketboards.org/linux-socfpga-next.git. It would be trivial for us to maintain a u-boot repo at the same location.
"a large flurry of patches flying around"? Funny, that I have not been CCed on any of these patches.
Chin-Liang, have you been?
Dinh
On Thursday, September 11, 2014 at 06:01:31 PM, Dinh Nguyen wrote:
On Wed, Sep 10, 2014 at 6:33 PM, Marek Vasut marex@denx.de wrote:
Hello,
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
I maintain a linux git repo at git://git.rocketboards.org/linux-socfpga-next.git. It would be trivial for us to maintain a u-boot repo at the same location.
The preferred way in the mainline U-Boot development is to have all the repositories in the same place, that is, git.denx.de git server.
"a large flurry of patches flying around"? Funny, that I have not been CCed on any of these patches.
Chin-Liang, have you been?
I think. Mr. See was on CC for all the patches Pavel sent at least. I'll keep you on CC as well.
Best regards, Marek Vasut
Hi!
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
I maintain a linux git repo at git://git.rocketboards.org/linux-socfpga-next.git. It would be trivial for us to maintain a u-boot repo at the same location.
"a large flurry of patches flying around"? Funny, that I have not been CCed on any of these patches.
Chin-Liang, have you been?
I'm sorry about that. I understood you are working on Linux, and only seen u-boot patches from Chin-Liang, so I cc-ed him..
Anyway, you can ignore those patches now, Marek actually transformed those patches into rather nice series ([PATCH 00/35][RFC] arm: socfpga: Usability fixes).
Best regards, and sorry for the confusion, Pavel
On Tue, 2014-09-16 at 11:56 +0200, ZY - pavel wrote:
Hi!
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
I maintain a linux git repo at git://git.rocketboards.org/linux-socfpga-next.git. It would be trivial for us to maintain a u-boot repo at the same location.
"a large flurry of patches flying around"? Funny, that I have not been CCed on any of these patches.
Chin-Liang, have you been?
I'm sorry about that. I understood you are working on Linux, and only seen u-boot patches from Chin-Liang, so I cc-ed him..
Hi guys,
To move things forward, I would propose myself to act as the custodian for the SOCFPGA repository after discussing with Dinh. I have been active on U-Boot forum and hopefully build up some credibility :). At same time, this will enforce someone from Altera (Dinh, Vince and myself) to review and ack each submitted patch. We would also able to help to test and offer any troubleshooting assistant to the patch submitter.
Hopefully would get a green light from everyone. We really appreciate Marek's suggestion as the repo is a great idea to speed up the SOCFPGA patch submission process. It will offload some of Albert's heavy load too as currently we heavily rely for Albert to integrate SOCFPGA patches. Due to that, to benefit everyone, we would like to have this repo as soon as possible.
Thanks Chin Liang
Anyway, you can ignore those patches now, Marek actually transformed those patches into rather nice series ([PATCH 00/35][RFC] arm: socfpga: Usability fixes).
Best regards, and sorry for the confusion, Pavel
Hi guys,
On Wed, 2014-09-17 at 06:54 -0500, Chin Liang See wrote:
On Tue, 2014-09-16 at 11:56 +0200, ZY - pavel wrote:
Hi!
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
I maintain a linux git repo at git://git.rocketboards.org/linux-socfpga-next.git. It would be trivial for us to maintain a u-boot repo at the same location.
"a large flurry of patches flying around"? Funny, that I have not been CCed on any of these patches.
Chin-Liang, have you been?
I'm sorry about that. I understood you are working on Linux, and only seen u-boot patches from Chin-Liang, so I cc-ed him..
Hi guys,
To move things forward, I would propose myself to act as the custodian for the SOCFPGA repository after discussing with Dinh. I have been active on U-Boot forum and hopefully build up some credibility :). At same time, this will enforce someone from Altera (Dinh, Vince and myself) to review and ack each submitted patch. We would also able to help to test and offer any troubleshooting assistant to the patch submitter.
Hopefully would get a green light from everyone. We really appreciate Marek's suggestion as the repo is a great idea to speed up the SOCFPGA patch submission process. It will offload some of Albert's heavy load too as currently we heavily rely for Albert to integrate SOCFPGA patches. Due to that, to benefit everyone, we would like to have this repo as soon as possible.
Thanks Chin Liang
Wonder any green light on this? The repo would help to speed up the SOCFPGA development especially for the on-going reviewing and testing of Marek's patches. Thanks
Chin Liang
On Fri, Sep 19, 2014 at 04:54:05AM -0500, Chin Liang See wrote:
Hi guys,
On Wed, 2014-09-17 at 06:54 -0500, Chin Liang See wrote:
On Tue, 2014-09-16 at 11:56 +0200, ZY - pavel wrote:
Hi!
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
I maintain a linux git repo at git://git.rocketboards.org/linux-socfpga-next.git. It would be trivial for us to maintain a u-boot repo at the same location.
"a large flurry of patches flying around"? Funny, that I have not been CCed on any of these patches.
Chin-Liang, have you been?
I'm sorry about that. I understood you are working on Linux, and only seen u-boot patches from Chin-Liang, so I cc-ed him..
Hi guys,
To move things forward, I would propose myself to act as the custodian for the SOCFPGA repository after discussing with Dinh. I have been active on U-Boot forum and hopefully build up some credibility :). At same time, this will enforce someone from Altera (Dinh, Vince and myself) to review and ack each submitted patch. We would also able to help to test and offer any troubleshooting assistant to the patch submitter.
Hopefully would get a green light from everyone. We really appreciate Marek's suggestion as the repo is a great idea to speed up the SOCFPGA patch submission process. It will offload some of Albert's heavy load too as currently we heavily rely for Albert to integrate SOCFPGA patches. Due to that, to benefit everyone, we would like to have this repo as soon as possible.
Wonder any green light on this? The repo would help to speed up the SOCFPGA development especially for the on-going reviewing and testing of Marek's patches. Thanks
OK, I've thought about this a lot. I think the best way forward is to have a new tree on git.denx.de, u-boot-socfpga that Marek will run for the v2014.10 merge window. This will give the Altera team time to get up to speed and build up their reputation in the community so that with the v2015.01 window they can take things over.
Wolfgang or Detlev, please make the new tree, thanks guys!
Dear Tom,
In message 20140923125419.GB25506@bill-the-cat you wrote:
OK, I've thought about this a lot. I think the best way forward is to have a new tree on git.denx.de, u-boot-socfpga that Marek will run for the v2014.10 merge window. This will give the Altera team time to get up to speed and build up their reputation in the community so that with the v2015.01 window they can take things over.
Wolfgang or Detlev, please make the new tree, thanks guys!
Done - thanks.
What about the u-boot-uniphier repository?
Best regards,
Wolfgang Denk
On Tue, Sep 23, 2014 at 03:43:02PM +0200, Wolfgang Denk wrote:
Dear Tom,
In message 20140923125419.GB25506@bill-the-cat you wrote:
OK, I've thought about this a lot. I think the best way forward is to have a new tree on git.denx.de, u-boot-socfpga that Marek will run for the v2014.10 merge window. This will give the Altera team time to get up to speed and build up their reputation in the community so that with the v2015.01 window they can take things over.
Wolfgang or Detlev, please make the new tree, thanks guys!
Done - thanks.
What about the u-boot-uniphier repository?
I thought that was done already, oops, so yes, that's fine too.
Dear Tom,
In message 20140923134613.GC25506@bill-the-cat you wrote:
What about the u-boot-uniphier repository?
I thought that was done already, oops, so yes, that's fine too.
Done now, thanks.
Best regards,
Wolfgang Denk
On Thursday, September 11, 2014 at 09:46:18 AM, Wolfgang Denk wrote:
Dear Michal,
In message 54112B64.5010104@monstr.eu you wrote:
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it.
+1 , having separate u-boot-zynq would be a good idea. It doesn't "cost" much and greatly improves the organisation.
I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information.
In socfpga case I think there are guys from Altera who maintain it.
Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this.
As far as I am concerned, I support both Marek's and Masahiro's requests.
@ Marek and Masahiro: if we reach an agreement to create such repos, please send me your SSH public keys that shall be used for these. Also, what should the names be - u-boot-socfpga ?
U-Boot-socfpga works OK I'd say -- it would cover all of Cyclone and Arria and Stratix socfpga families.
Also, my SSH key should already be in position for u-boot-usb and u-boot-pxa ;-)
Thank you!
Best regards, Marek Vasut
On Thu, Sep 11, 2014 at 2:46 AM, Wolfgang Denk wd@denx.de wrote:
Dear Michal,
In message 54112B64.5010104@monstr.eu you wrote:
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it.
rocketboards.org is our portal. Linux and u-boot currently have repos there. This will be our central place for uboot and Linux. PERIOD!
I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information.
In socfpga case I think there are guys from Altera who maintain it.
Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this.
Thanks Marek for your volunteer, but we would like to maintain our git repo at rocketboards.org.
Dinh
As far as I am concerned, I support both Marek's and Masahiro's requests.
@ Marek and Masahiro: if we reach an agreement to create such repos, please send me your SSH public keys that shall be used for these. Also, what should the names be - u-boot-socfpga ? And u-boot-uniphier ? [But is there not a chance that Pana- sonic might have other SoCs that might be mainlines? So maybe we should use u-boot-panasonic instead?]
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@denx.de Laughter and tears are meant to turn the wheels of the same machinery of sensibility; one is wind-power, and the other water-power. - Oliver Wendell Holmes, Sr. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Thursday, September 11, 2014 at 06:14:55 PM, Dinh Nguyen wrote:
On Thu, Sep 11, 2014 at 2:46 AM, Wolfgang Denk wd@denx.de wrote:
Dear Michal,
In message 54112B64.5010104@monstr.eu you wrote:
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it.
rocketboards.org is our portal. Linux and u-boot currently have repos there.
I'm OK with this.
This will be our central place for uboot and Linux. PERIOD!
I am OK with this as well. But I want to use mainline U-Boot on my board, which I cannot seem to find on the rocketboards website. I only see an ancient 2013.01.01 and I don't see anyone feeding the rocketboards patches into mainline either.
Charles and Pavel have been a great help so far in sending U-Boot patches for SoCFPGA into mainline, but so far we lack coordination there. Thus, I decided to take that up and collect all their effort so they're not lost.
That said, I'd be glad if someone from Altera would step up and work on the mainline support for SoCFPGA properly, pick the patches and maintain the repository.
I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information.
In socfpga case I think there are guys from Altera who maintain it.
Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this.
Thanks Marek for your volunteer, but we would like to maintain our git repo at rocketboards.org.
I am not asking you to stop working on your repository, please do not misunderstand my intention.
Best regards, Marek Vasut
On 09/11/2014 11:51 AM, Marek Vasut wrote:
On Thursday, September 11, 2014 at 06:14:55 PM, Dinh Nguyen wrote:
On Thu, Sep 11, 2014 at 2:46 AM, Wolfgang Denk wd@denx.de wrote:
Dear Michal,
In message 54112B64.5010104@monstr.eu you wrote:
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it.
rocketboards.org is our portal. Linux and u-boot currently have repos there.
I'm OK with this.
This will be our central place for uboot and Linux. PERIOD!
I am OK with this as well. But I want to use mainline U-Boot on my board, which I cannot seem to find on the rocketboards website. I only see an ancient 2013.01.01 and I don't see anyone feeding the rocketboards patches into mainline either.
Charles and Pavel have been a great help so far in sending U-Boot patches for SoCFPGA into mainline, but so far we lack coordination there. Thus, I decided to take that up and collect all their effort so they're not lost.
That said, I'd be glad if someone from Altera would step up and work on the mainline support for SoCFPGA properly, pick the patches and maintain the repository.
Honestly, I have not seen any patches for SOCFPGA come my way. I don't think I would ignore them if they did. Please CC me and Vince on any future uboot support for SOCFPGA. We will make sure they are collected and posted to u-boot-socfpga-next.git.
Like everything, there's only so many hours in a day. I am fully aware of our lack of uboot mainline support. It's very high on our list, but that darn Linux thing sometimes get in the way. We have added an additional resource internally, Vince Bridgers, to help us mainline u-boot support.
I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information.
In socfpga case I think there are guys from Altera who maintain it.
Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this.
Thanks Marek for your volunteer, but we would like to maintain our git repo at rocketboards.org.
I am not asking you to stop working on your repository, please do not misunderstand my intention.
Not at all.
Dinh
On Thu, Sep 11, 2014 at 11:14:55AM -0500, Dinh Nguyen wrote:
On Thu, Sep 11, 2014 at 2:46 AM, Wolfgang Denk wd@denx.de wrote:
Dear Michal,
In message 54112B64.5010104@monstr.eu you wrote:
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it.
rocketboards.org is our portal. Linux and u-boot currently have repos there. This will be our central place for uboot and Linux. PERIOD!
Alright. The sunxi community has recently made some great strides in getting things merged from their tree into mainline (And again, yaaaay, thanks for the hard work there guys!). What is the plan to get things up-lifted and merged to mainline for this SoC?
On 09/11/2014 12:14 PM, Tom Rini wrote:
On Thu, Sep 11, 2014 at 11:14:55AM -0500, Dinh Nguyen wrote:
On Thu, Sep 11, 2014 at 2:46 AM, Wolfgang Denk wd@denx.de wrote:
Dear Michal,
In message 54112B64.5010104@monstr.eu you wrote:
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it.
rocketboards.org is our portal. Linux and u-boot currently have repos there. This will be our central place for uboot and Linux. PERIOD!
Alright. The sunxi community has recently made some great strides in getting things merged from their tree into mainline (And again, yaaaay, thanks for the hard work there guys!). What is the plan to get things up-lifted and merged to mainline for this SoC?
Understood...You have just lit a fire in our arses! We have added a resource internally, Vince Bridgers, to help us upstream more u-boot support. Also, now that Linux support for SOCFPGA is decent, I will focus more on u-boot.
Thanks, Dinh
Dear Dinh,
In message 54122DE5.1080006@opensource.altera.com you wrote:
Understood...You have just lit a fire in our arses! We have added a resource internally, Vince Bridgers, to help us upstream more u-boot support. Also, now that Linux support for SOCFPGA is decent, I will focus more on u-boot.
That's great to hear, thank.
So I suggest we create u-boot-socfpga now, as this will be needed in any case when any significant amount of patches is coming in for mainline.
For now, we assing Marek as custodian - he has volunteered, and he already has a reputation in the community. As soon as Vince starts actively working here on the mailing list, we can switch this role to him.
What do you think?
Best regards,
Wolfgang Denk
On 09/12/2014 12:25 AM, Wolfgang Denk wrote:
Dear Dinh,
In message 54122DE5.1080006@opensource.altera.com you wrote:
Understood...You have just lit a fire in our arses! We have added a resource internally, Vince Bridgers, to help us upstream more u-boot support. Also, now that Linux support for SOCFPGA is decent, I will focus more on u-boot.
That's great to hear, thank.
So I suggest we create u-boot-socfpga now, as this will be needed in any case when any significant amount of patches is coming in for mainline.
For now, we assing Marek as custodian - he has volunteered, and he already has a reputation in the community. As soon as Vince starts actively working here on the mailing list, we can switch this role to him.
NO..we'd like to maintain the u-boot-socfpga-next git repo at rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively maintain it from now on.
I went back to the mailing list last night and you're right, there were quite a few patches that had Chin-Liang's ACK, but sat idle. I'll start to pull those patches in ASAP.
Thanks, Dinh
Dear Dinh,
In message 54133B22.2090509@opensource.altera.com you wrote:
So I suggest we create u-boot-socfpga now, as this will be needed in any case when any significant amount of patches is coming in for mainline.
For now, we assing Marek as custodian - he has volunteered, and he already has a reputation in the community. As soon as Vince starts actively working here on the mailing list, we can switch this role to him.
NO..we'd like to maintain the u-boot-socfpga-next git repo at rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively maintain it from now on.
I'm sorry, but that's not the way how the U-Boot community works.
To get patches or new code into U-Boot mainline, these have to be submitted to the U-Boot mailing list (among other purposes for archival and that they get stored in the patchwork database). Then a peer review takes place, and the responsible custodian finally applies these patches to the respective custodian repository. Finally, he sends a pull request to the next higher custodian - in case of SoCFPGA that would be Albert as ARM custodian.
There is nothing wrong with you maintaining u-boot-socfpga-next at rocketboards.org. It's just that such code does not get into mainline other than by the procedure described before. So we need the custodian repository in any way (unless Albert says he wants to take stuff directly into the ARM repo - but from the amount of work that is going on this seems unwise). Vince may of course volunteer as custodian for the new u-boot-socfpga repository, but that would be a community decision, and like everybody else in that role he needs to earn some reputation first - we haven't seen him at work so far. In the meantime, it appears to make sense that Marek fills in the gap.
Best regards,
Wolfgang Denk
On 09/12/2014 02:46 PM, Wolfgang Denk wrote:
Dear Dinh,
In message 54133B22.2090509@opensource.altera.com you wrote:
So I suggest we create u-boot-socfpga now, as this will be needed in any case when any significant amount of patches is coming in for mainline.
For now, we assing Marek as custodian - he has volunteered, and he already has a reputation in the community. As soon as Vince starts actively working here on the mailing list, we can switch this role to him.
NO..we'd like to maintain the u-boot-socfpga-next git repo at rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively maintain it from now on.
I'm sorry, but that's not the way how the U-Boot community works.
To get patches or new code into U-Boot mainline, these have to be submitted to the U-Boot mailing list (among other purposes for archival and that they get stored in the patchwork database). Then a peer review takes place, and the responsible custodian finally applies these patches to the respective custodian repository. Finally, he sends a pull request to the next higher custodian - in case of SoCFPGA that would be Albert as ARM custodian.
Does the above process differ from the Linux community process in anyway? If not, then I've been doing the same for the Linux support for SOCFPGA on the rocketboards. The ARM-SOC maintainers have been pulling from the git repo at rocketboards for quite some time now. I think I can probably do the same for u-boot.
Dinh
Dear Dinh,
In message 54136276.6040109@opensource.altera.com you wrote:
To get patches or new code into U-Boot mainline, these have to be submitted to the U-Boot mailing list (among other purposes for archival and that they get stored in the patchwork database). Then a peer review takes place, and the responsible custodian finally applies these patches to the respective custodian repository. Finally, he sends a pull request to the next higher custodian - in case of SoCFPGA that would be Albert as ARM custodian.
Does the above process differ from the Linux community process in anyway? If not, then I've been doing the same for the Linux support for SOCFPGA on the rocketboards. The ARM-SOC maintainers have been pulling from the git repo at rocketboards for quite some time now. I think I can probably do the same for u-boot.
I think we are a bit more critical here in U-Boot. The repositories we pull from are maintained by community-assigned custodians, who have a proven track record not only as experienced developers, but also for working with the community and being able to negotiate conflicts.
If Vince gets appointed as custodian for socfpga, there should be no problem for him to automatically synchronize your u-boot-socfpga-next.git repository with the U-Boot u-boot-socfpga one.
On the other hand - what exactly is the code you are referring to in u-boot-socfpga-next.git ? At the moment, I see this:
-> git clone git://git.rocketboards.org/u-boot-socfpga-next.git Cloning into 'u-boot-socfpga-next'... warning: You appear to have cloned an empty repository. Checking connectivity... done.
Best regards,
Wolfgang Denk
On 09/12/2014 05:14 PM, Wolfgang Denk wrote:
Dear Dinh,
In message 54136276.6040109@opensource.altera.com you wrote:
To get patches or new code into U-Boot mainline, these have to be submitted to the U-Boot mailing list (among other purposes for archival and that they get stored in the patchwork database). Then a peer review takes place, and the responsible custodian finally applies these patches to the respective custodian repository. Finally, he sends a pull request to the next higher custodian - in case of SoCFPGA that would be Albert as ARM custodian.
Does the above process differ from the Linux community process in anyway? If not, then I've been doing the same for the Linux support for SOCFPGA on the rocketboards. The ARM-SOC maintainers have been pulling from the git repo at rocketboards for quite some time now. I think I can probably do the same for u-boot.
I think we are a bit more critical here in U-Boot. The repositories we pull from are maintained by community-assigned custodians, who have a proven track record not only as experienced developers, but also for working with the community and being able to negotiate conflicts.
If Vince gets appointed as custodian for socfpga, there should be no problem for him to automatically synchronize your u-boot-socfpga-next.git repository with the U-Boot u-boot-socfpga one.
Then I vote for myself as the custodian for u-boot-socfpga. By the way, what is the difference between a Maintainer and a custodian? I don't understand why if Chin-Liang and myself are listed as Maintainer(s) for SOCFPGA, we would have to rely on Marek to pull in our patches for SOCFPGA?
On the other hand - what exactly is the code you are referring to in u-boot-socfpga-next.git ? At the moment, I see this:
-> git clone git://git.rocketboards.org/u-boot-socfpga-next.git Cloning into 'u-boot-socfpga-next'... warning: You appear to have cloned an empty repository. Checking connectivity... done.
Yes, this is the repo will be the one that we will use. I have a couple of other things on my plate at the moment and will populate this repo shortly.
Dinh
Dear Dinh,
In message 541373AD.4020902@opensource.altera.com you wrote:
Then I vote for myself as the custodian for u-boot-socfpga. By the way,
May I ask what made you change your mind like that? First you wrote that Vince was assigned to to that, and now it's suddenly you? As far as I can see, you have not participated in any SoCPGA related code reviews or discussions in 2014 at all, so what would be the difference?
what is the difference between a Maintainer and a custodian? I don't understand why if Chin-Liang and myself are listed as Maintainer(s) for SOCFPGA, we would have to rely on Marek to pull in our patches for SOCFPGA?
A maintainer is someone who developed some piece of code and feels responsible for it - who is available as contact person for questions, or who will be asked to fix any bugs in that code.
A Custodian is "one that guards and protects or maintains" [1], i. e. he is responsible for maintaining the design principles of U-Boot and the code quality even for code he did not work on himself, and for patches submitted by others. This is a job that carries a much higher responsibility than just maintaining your own code. He will interface to the actual maintainers of the respective code, negotiatiate solutions and decide in case of conflicts.
[1] http://www.merriam-webster.com/dictionary/custodian
Yes, this is the repo will be the one that we will use. I have a couple of other things on my plate at the moment and will populate this repo shortly.
Thats great, as it means you will not lose any efforts when we start with u-boot-socfpga now, as you then can start with synchronized repositories right from the beginning.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On 9/12/14, 5:51 PM, Wolfgang Denk wrote:
Dear Dinh,
In message 541373AD.4020902@opensource.altera.com you wrote:
Then I vote for myself as the custodian for u-boot-socfpga. By the way,
May I ask what made you change your mind like that? First you wrote that Vince was assigned to to that, and now it's suddenly you? As far as I can see, you have not participated in any SoCPGA related code reviews or discussions in 2014 at all, so what would be the difference?
Touche...
what is the difference between a Maintainer and a custodian? I don't understand why if Chin-Liang and myself are listed as Maintainer(s) for SOCFPGA, we would have to rely on Marek to pull in our patches for SOCFPGA?
A maintainer is someone who developed some piece of code and feels responsible for it - who is available as contact person for questions, or who will be asked to fix any bugs in that code.
A Custodian is "one that guards and protects or maintains" [1], i. e. he is responsible for maintaining the design principles of U-Boot and the code quality even for code he did not work on himself, and for patches submitted by others. This is a job that carries a much higher responsibility than just maintaining your own code. He will interface to the actual maintainers of the respective code, negotiatiate solutions and decide in case of conflicts.
[1] http://www.merriam-webster.com/dictionary/custodian
Yes, this is the repo will be the one that we will use. I have a couple of other things on my plate at the moment and will populate this repo shortly.
Thats great, as it means you will not lose any efforts when we start with u-boot-socfpga now, as you then can start with synchronized repositories right from the beginning.
FWIW, I strongly oppose assigning an external person to be the custodian for socfpga. Marek is fantastic developer, and my only issue is that he is not an Altera employee. I contend that an in-house custodian for socfpga is the best choice. I know that my voice carries little weight here, but I would, at least, think I have Altera's best interest in mind here.
Also, I went back and look at the "flurry" of patches for socfpga, and I must commend Tom Rini on a fantastic job for applying the patches. I was only able to find 1 patch that needed addressing:
[socfpga: generic board for socfpga] from Pavel Machek
For now, I have it applied to
git://git.rocketboards.org/u-boot-socfpga-next.git for_next branch.
There are a few patches that needs to be addressed in the mailing list, but I don't see any other patches that needs to be applied at this moment. Please correct me if I'm wrong.
To summarize, have we failed as maintainers of socfpga that you would need to assign somebody else to be the custodian for socfpga? If so, I apologize and would like for you to reconsider your position and let us try to do a better job.
Thanks, Dinh
On Sun, Sep 14, 2014 at 11:02:08AM -0500, Dinh Nguyen wrote:
Hi Wolfgang,
On 9/12/14, 5:51 PM, Wolfgang Denk wrote:
Dear Dinh,
In message 541373AD.4020902@opensource.altera.com you wrote:
Then I vote for myself as the custodian for u-boot-socfpga. By the way,
May I ask what made you change your mind like that? First you wrote that Vince was assigned to to that, and now it's suddenly you? As far as I can see, you have not participated in any SoCPGA related code reviews or discussions in 2014 at all, so what would be the difference?
Touche...
what is the difference between a Maintainer and a custodian? I don't understand why if Chin-Liang and myself are listed as Maintainer(s) for SOCFPGA, we would have to rely on Marek to pull in our patches for SOCFPGA?
A maintainer is someone who developed some piece of code and feels responsible for it - who is available as contact person for questions, or who will be asked to fix any bugs in that code.
A Custodian is "one that guards and protects or maintains" [1], i. e. he is responsible for maintaining the design principles of U-Boot and the code quality even for code he did not work on himself, and for patches submitted by others. This is a job that carries a much higher responsibility than just maintaining your own code. He will interface to the actual maintainers of the respective code, negotiatiate solutions and decide in case of conflicts.
[1] http://www.merriam-webster.com/dictionary/custodian
Yes, this is the repo will be the one that we will use. I have a couple of other things on my plate at the moment and will populate this repo shortly.
Thats great, as it means you will not lose any efforts when we start with u-boot-socfpga now, as you then can start with synchronized repositories right from the beginning.
FWIW, I strongly oppose assigning an external person to be the custodian for socfpga. Marek is fantastic developer, and my only issue is that he is not an Altera employee. I contend that an in-house custodian for socfpga is the best choice. I know that my voice carries little weight here, but I would, at least, think I have Altera's best interest in mind here.
I don't think it's a bad thing for the custodian for a given SoC to be an employee of the vendor as they're likely to have more insight into how things really work and be able to get questions answered about how/why a magic bit needs to be set.
Also, I went back and look at the "flurry" of patches for socfpga, and I must commend Tom Rini on a fantastic job for applying the patches. I was only able to find 1 patch that needed addressing:
[socfpga: generic board for socfpga] from Pavel Machek
Can you test it, and Reviewed-by/Acked-by/Tested-by or something the patch? patchwork collects these and that is a big part of our review and merge process here.
For now, I have it applied to
git://git.rocketboards.org/u-boot-socfpga-next.git for_next branch.
Here's a difference from the Linux kernel community. We really do want to use a git tree hosted on git.denx.de for pulls.
There are a few patches that needs to be addressed in the mailing list, but I don't see any other patches that needs to be applied at this moment. Please correct me if I'm wrong.
To summarize, have we failed as maintainers of socfpga that you would need to assign somebody else to be the custodian for socfpga? If so, I apologize and would like for you to reconsider your position and let us try to do a better job.
Just like in the kernel community, it's a position that has to be earned. I understand there should be big round of patches posted soon, which will be a good place to see follow-through. There's also the denali NAND patches which are blocking another SoC from going in as well which I'm hoping to see v10 of posted sometime in the coming week.
Hi Tom,
On Sun, 2014-09-14 at 12:46 -0400, ZY - trini wrote:
On Sun, Sep 14, 2014 at 11:02:08AM -0500, Dinh Nguyen wrote:
Hi Wolfgang,
On 9/12/14, 5:51 PM, Wolfgang Denk wrote:
Dear Dinh,
In message 541373AD.4020902@opensource.altera.com you wrote:
Also, I went back and look at the "flurry" of patches for socfpga, and I must commend Tom Rini on a fantastic job for applying the patches. I was only able to find 1 patch that needed addressing:
[socfpga: generic board for socfpga] from Pavel Machek
Can you test it, and Reviewed-by/Acked-by/Tested-by or something the patch? patchwork collects these and that is a big part of our review and merge process here.
This is actually a big patch which should be split to smaller patch. Nevertheless, I already started reviewing it last week and hopefully can get it reviewed by today.
For now, I have it applied to
git://git.rocketboards.org/u-boot-socfpga-next.git for_next branch.
Here's a difference from the Linux kernel community. We really do want to use a git tree hosted on git.denx.de for pulls.
There are a few patches that needs to be addressed in the mailing list, but I don't see any other patches that needs to be applied at this moment. Please correct me if I'm wrong.
To summarize, have we failed as maintainers of socfpga that you would need to assign somebody else to be the custodian for socfpga? If so, I apologize and would like for you to reconsider your position and let us try to do a better job.
Just like in the kernel community, it's a position that has to be earned. I understand there should be big round of patches posted soon, which will be a good place to see follow-through. There's also the denali NAND patches which are blocking another SoC from going in as well which I'm hoping to see v10 of posted sometime in the coming week.
The v10 NAND patch was posted last week. In fact, the patch was working for both Altera and Panasonic since v7. It takes up to v10 as I received some late comments.
At same time, just fyi, there is slowness for for last few patches as I was on paternity leave for last few weeks :)
Thanks Chin Liang
On Monday, September 15, 2014 at 03:07:11 AM, Chin Liang See wrote:
Hi Tom,
On Sun, 2014-09-14 at 12:46 -0400, ZY - trini wrote:
On Sun, Sep 14, 2014 at 11:02:08AM -0500, Dinh Nguyen wrote:
Hi Wolfgang,
On 9/12/14, 5:51 PM, Wolfgang Denk wrote:
Dear Dinh,
In message 541373AD.4020902@opensource.altera.com you wrote:
Also, I went back and look at the "flurry" of patches for socfpga, and I must commend Tom Rini on a fantastic job for applying the patches. I was only able to find 1 patch that needed addressing:
[socfpga: generic board for socfpga] from Pavel Machek
Can you test it, and Reviewed-by/Acked-by/Tested-by or something the patch? patchwork collects these and that is a big part of our review and merge process here.
This is actually a big patch which should be split to smaller patch. Nevertheless, I already started reviewing it last week and hopefully can get it reviewed by today.
I did manage to split that big patch, clean it up and update it to match the latest rocketboards 2013.01.01 code. Please give me a few more days to finish with this and post the result. It's about 50 patches so far. I can send them to you off-list if you want to check them early.
So far, the SPL cannot be built and I still depend on the one generated by Quartus. On the other hand , the rest of the U-Boot works well, incl. ethernet and SDMMC . I also fixed L1 and L2 cache issues all over the place and cleaned up the code, so the thing is also much faster now.
For now, I have it applied to
git://git.rocketboards.org/u-boot-socfpga-next.git for_next branch.
Here's a difference from the Linux kernel community. We really do want to use a git tree hosted on git.denx.de for pulls.
There are a few patches that needs to be addressed in the mailing list, but I don't see any other patches that needs to be applied at this moment. Please correct me if I'm wrong.
To summarize, have we failed as maintainers of socfpga that you would need to assign somebody else to be the custodian for socfpga? If so, I apologize and would like for you to reconsider your position and let us try to do a better job.
Just like in the kernel community, it's a position that has to be earned. I understand there should be big round of patches posted soon, which will be a good place to see follow-through. There's also the denali NAND patches which are blocking another SoC from going in as well which I'm hoping to see v10 of posted sometime in the coming week.
The v10 NAND patch was posted last week. In fact, the patch was working for both Altera and Panasonic since v7. It takes up to v10 as I received some late comments.
At same time, just fyi, there is slowness for for last few patches as I was on paternity leave for last few weeks :)
No worries.
Best regards, Marek Vasut
Dear Marex,
On Mon, 2014-09-15 at 03:27 +0200, marex@denx.de wrote:
On Monday, September 15, 2014 at 03:07:11 AM, Chin Liang See wrote:
Hi Tom,
On Sun, 2014-09-14 at 12:46 -0400, ZY - trini wrote:
On Sun, Sep 14, 2014 at 11:02:08AM -0500, Dinh Nguyen wrote:
Hi Wolfgang,
On 9/12/14, 5:51 PM, Wolfgang Denk wrote:
Dear Dinh,
In message 541373AD.4020902@opensource.altera.com you wrote:
Also, I went back and look at the "flurry" of patches for socfpga, and I must commend Tom Rini on a fantastic job for applying the patches. I was only able to find 1 patch that needed addressing:
[socfpga: generic board for socfpga] from Pavel Machek
Can you test it, and Reviewed-by/Acked-by/Tested-by or something the patch? patchwork collects these and that is a big part of our review and merge process here.
This is actually a big patch which should be split to smaller patch. Nevertheless, I already started reviewing it last week and hopefully can get it reviewed by today.
I did manage to split that big patch, clean it up and update it to match the latest rocketboards 2013.01.01 code. Please give me a few more days to finish with this and post the result. It's about 50 patches so far. I can send them to you off-list if you want to check them early.
Sure, will hear more from you then. In the mean time, I can provide my comments on the big patch today so we can speed this up.
So far, the SPL cannot be built and I still depend on the one generated by Quartus.
Yup, the missing driver is the SDRAM which is due to legal complication. I believe its resolved now and will send the first patch soon. Hopefully this would get the SPL build and running.
On the other hand , the rest of the U-Boot works well, incl. ethernet and SDMMC . I also fixed L1 and L2 cache issues all over the place and cleaned up the code, so the thing is also much faster now.
Great to hear that. Thanks for verifying that the U-Boot is working too. Thanks again for your helps! And Pavel plus his ACKs :)
Thanks Chin Liang
On Monday, September 15, 2014 at 03:43:39 AM, Chin Liang See wrote:
Dear Marex,
[..]
This is actually a big patch which should be split to smaller patch. Nevertheless, I already started reviewing it last week and hopefully can get it reviewed by today.
I did manage to split that big patch, clean it up and update it to match the latest rocketboards 2013.01.01 code. Please give me a few more days to finish with this and post the result. It's about 50 patches so far. I can send them to you off-list if you want to check them early.
Sure, will hear more from you then. In the mean time, I can provide my comments on the big patch today so we can speed this up.
So far, the SPL cannot be built and I still depend on the one generated by Quartus.
Yup, the missing driver is the SDRAM which is due to legal complication. I believe its resolved now and will send the first patch soon. Hopefully this would get the SPL build and running.
OK, that's good, thanks !
On the other hand , the rest of the U-Boot works well, incl. ethernet and SDMMC . I also fixed L1 and L2 cache issues all over the place and cleaned up the code, so the thing is also much faster now.
Great to hear that. Thanks for verifying that the U-Boot is working too. Thanks again for your helps! And Pavel plus his ACKs :)
Sure, you're welcome. I'll keep you guys in the loop.
Best regards, Marek Vasut
Dear Dinh,
In message 5415BC00.6090407@opensource.altera.com you wrote:
FWIW, I strongly oppose assigning an external person to be the custodian for socfpga. Marek is fantastic developer, and my only issue is that he is not an Altera employee. I contend that an in-house custodian for socfpga is the best choice. I know that my voice carries little weight here, but I would, at least, think I have Altera's best interest in mind here.
There are several other cases where the custodian for a SoC family is not an employee of the SoC vendor - see for example Stefano Babic for the Freescale i.MX family, ot Stefan Roese for the APM PowerPC, or Andreas Bießmann for Atmel, or Marek for Marvell, etc. etc.
To summarize, have we failed as maintainers of socfpga that you would need to assign somebody else to be the custodian for socfpga?
You have not failed in any way. You simply have not participated in the community work at all so far. Nobody here on the list knows how you work.
When we initially assign Marek as custodian, that does not mean that you cannot drive the development - on contrary. Marek will be extremely helpful for each help he can get, like code reviews, test reports etc. for any submitted patches. Actually you can still do _all_ the work, with him just being the responsible person until the community has seen you at work. I repeat, switching the responsibility for a repository is just a trivial act - a one-line edit to a file...
We all will be happy if Altera really starts working actively within the U-Boot community. But such work is like producing code: it is not sufficient to write code and put it up somewhere, it needs to get reviewed by the community before it gets accepted for mainline; in the same way, the working style of a potential custodian needs to be reviewed by the community before they accept him in that role.
Best regards,
Wolfgang Denk
Hi all
Il 12/set/2014 21:53 "Dinh Nguyen" dinguyen@opensource.altera.com ha scritto:
On 09/12/2014 12:25 AM, Wolfgang Denk wrote:
Dear Dinh,
In message 54122DE5.1080006@opensource.altera.com you wrote:
Understood...You have just lit a fire in our arses! We have added a resource internally, Vince Bridgers, to help us upstream more u-boot support. Also, now that Linux support for SOCFPGA is decent, I will focus more on u-boot.
That's great to hear, thank.
So I suggest we create u-boot-socfpga now, as this will be needed in any case when any significant amount of patches is coming in for mainline.
For now, we assing Marek as custodian - he has volunteered, and he already has a reputation in the community. As soon as Vince starts actively working here on the mailing list, we can switch this role to him.
NO..we'd like to maintain the u-boot-socfpga-next git repo at rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively maintain it from now on.
I went back to the mailing list last night and you're right, there were quite a few patches that had Chin-Liang's ACK, but sat idle. I'll start to pull those patches in ASAP.
If patches are in U-Boot mailing list, i don't see any problem to pull from their server. You should only agree how review process should be done.
Michael
Thanks, Dinh
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi guys,
I'm going to jump in here with an end-user's perspective, along with an offer of assistance/contribution.
I'm interested in using Altera's SOCs in my designs. Altera guys - if you look over on the Altera Forum, you will see that I am very active over there (basically answering everyone's FPGA questions).
Up until now I have avoided any SoC development kits as I considered the software support to not have matured enough. I consider "mature" code to be code that I can checkout from mainline, where mainline is U-Boot via the Denx repos, and Linux via the Kernel repos.
Freescale has done this forever, and I hold their processors and code in high regard.
Texas Instruments has recently realized that this is the way to go, and have invested significantly in this area - as demonstrated by Tom Rini. TI have dedicated a page to mainlining:
http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page
TI have similarly gained my respect.
The fact that discussion is now occurring for Altera's SoCs indicates to me that a certain level of maturity has been reached and that it is now time for me to consider using these devices.
I'd like to help, and I'm sure Ira Snyder will help too (most likely more so than me). I would like to obtain some SoC development kits so as to help with the SoC "experience" for end-users.
To aid in this development, I'd like some recommendations on what hardware to buy. I've included the list below the body of this email (to save cluttering the flow of this discussion). Its possible for me to obtain one or more of these boards.
Which ones are supported in mainline U-Boot and Linux? What will it take to make it easier for the end-user like myself?
I would like to be able to buy something like the Critical Link or Denx modules and simply plug them into my custom hardware, configure the FPGA fabric with whatever custom "magic" I need, have Ira develop a custom drive to that "magic" and just have things *WORK*. As an end-user, I don't want to have to pull a dozen patches off the mailing list to get a working system.
Altera's success in the SoC market depends on "getting it right" with respect to integration with the open-source community. That integration involves playing by the established set of rules. Wolfgang and his (creation and) support of U-Boot is of immeasurable value to the open-source community.
Altera developers, please follow Wolfgang's advice.
Cheers, Dave Hawkins, California Institute of Technology.
------------------------------------------------------------------
1. Cyclone V SoC Development Kit
http://www.altera.com/products/devkits/altera/kit-cyclone-v-soc.html
This is the main kit that most people are probably developing with. At $1,795 its pretty expensive, but I could request a couple of kits from the Altera University Program.
2. Arria V SoC kit
http://www.altera.com/products/devkits/altera/kit-arria-v-soc.html
At $3,495 this is also very expensive. This board still ships with ES (Engineering Sample), so I would not buy this yet.
3. Terasic/Arrow SOCKit
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=81...
At $299 this is pretty reasonable.
4. SOC System-on-Modules
http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system...
eg, Critical Link MitySOM
http://www.criticallink.com/product/mitysom-5csx/
http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiM...
Each module is about $600 at Mouser.
5. Denx MCV board
These modules look reasonably priced.
The CriticalLink and Denx modules look suitable for my intended application, i.e., as the controller for a much larger FPGA board.
Wolfgang - feel free to advise me to use the Denx modules, and I'll take a more critical look at the data sheets to check they have the features I want to use.
Hi
Il 12/set/2014 23:16 "David Hawkins" dwh@ovro.caltech.edu ha scritto:
Hi guys,
I'm going to jump in here with an end-user's perspective, along with an offer of assistance/contribution.
I'm interested in using Altera's SOCs in my designs. Altera guys - if you look over on the Altera Forum, you will see that I am very active over there (basically answering everyone's FPGA questions).
Up until now I have avoided any SoC development kits as I considered the software support to not have matured enough. I consider "mature" code to be code that I can checkout from mainline, where mainline is U-Boot via the Denx repos, and Linux via the Kernel repos.
Freescale has done this forever, and I hold their processors and code in high regard.
Texas Instruments has recently realized that this is the way to go, and have invested significantly in this area - as demonstrated by Tom Rini. TI have dedicated a page to mainlining:
http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page
TI have similarly gained my respect.
The fact that discussion is now occurring for Altera's SoCs indicates to me that a certain level of maturity has been reached and that it is now time for me to consider using these devices.
I'd like to help, and I'm sure Ira Snyder will help too (most likely more so than me). I would like to obtain some SoC development kits so as to help with the SoC "experience" for end-users.
To aid in this development, I'd like some recommendations on what hardware to buy. I've included the list below the body of this email (to save cluttering the flow of this discussion). Its possible for me to obtain one or more of these boards.
Which ones are supported in mainline U-Boot and Linux? What will it take to make it easier for the end-user like myself?
I would like to be able to buy something like the Critical Link or Denx modules and simply plug them into my custom hardware, configure the FPGA fabric with whatever custom "magic" I need, have Ira develop a custom drive to that "magic" and just have things *WORK*. As an end-user, I don't want to have to pull a dozen patches off the mailing list to get a working system.
Altera's success in the SoC market depends on "getting it right" with respect to integration with the open-source community. That integration involves playing by the established set of rules. Wolfgang and his (creation and) support of U-Boot is of immeasurable value to the open-source community.
Altera developers, please follow Wolfgang's advice.
Cheers, Dave Hawkins, California Institute of Technology.
We know and thank you very much for price list ;)
Michael
Cyclone V SoC Development Kit
http://www.altera.com/products/devkits/altera/kit-cyclone-v-soc.html
This is the main kit that most people are probably developing with. At $1,795 its pretty expensive, but I could request a couple of kits from the Altera University Program.
Arria V SoC kit
http://www.altera.com/products/devkits/altera/kit-arria-v-soc.html
At $3,495 this is also very expensive. This board still ships with ES (Engineering Sample), so I would not buy this yet.
Terasic/Arrow SOCKit
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=81...
At $299 this is pretty reasonable.
- SOC System-on-Modules
http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system...
eg, Critical Link MitySOM
http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiM...
Each module is about $600 at Mouser.
Denx MCV board
These modules look reasonably priced.
The CriticalLink and Denx modules look suitable for my intended application, i.e., as the controller for a much larger FPGA board.
Wolfgang - feel free to advise me to use the Denx modules, and I'll take a more critical look at the data sheets to check they have the features I want to use.
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Michael,
We know and thank you very much for price list ;)
I hope my incomplete list of vendors did not offend you. I'm board vendor agnostic. If your company has an Altera SoC board, I'm more than happy to look at it too.
Feel free to offer alternative options :)
Cheers, Dave
Hi Dave
Il 12/set/2014 23:23 "David Hawkins" dwh@ovro.caltech.edu ha scritto:
Hi Michael,
We know and thank you very much for price list ;)
I hope my incomplete list of vendors did not offend you. I'm board vendor agnostic. If your company has an Altera SoC board, I'm more than happy to look at it too.
Feel free to offer alternative options :)
It was just nice. I'm agree with you but I don't see any problem to have different host domain at the end.
Michael
PS: tools take to much time to build design on my laptop
Cheers, Dave
On 09/12/2014 04:05 PM, David Hawkins wrote:
Hi guys,
I'm going to jump in here with an end-user's perspective, along with an offer of assistance/contribution.
I'm interested in using Altera's SOCs in my designs. Altera guys - if you look over on the Altera Forum, you will see that I am very active over there (basically answering everyone's FPGA questions).
Awesome...thank you for your support!
Up until now I have avoided any SoC development kits as I considered the software support to not have matured enough. I consider "mature" code to be code that I can checkout from mainline, where mainline is U-Boot via the Denx repos, and Linux via the Kernel repos.
For Linux, we have done a better job than u-boot. You should be able to have most of what you need from kernel.org for the Altera Devkits and Terasic SocKit board. The most important piece maybe the FPGA manager, otherwise the SOCFPGA platform is just any other A9 board.
The FPGA manager is in-flight:
https://lkml.org/lkml/2014/8/1/517
For U-boot, the upstreaming process has been slow. I admit it, but it is very high on our to-do list.
Freescale has done this forever, and I hold their processors and code in high regard.
I used to work at Freescale's doing the i.MX parts. I hope these were the processors you had in the mind?
Texas Instruments has recently realized that this is the way to go, and have invested significantly in this area - as demonstrated by Tom Rini. TI have dedicated a page to mainlining:
http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page
TI have similarly gained my respect.
The fact that discussion is now occurring for Altera's SoCs indicates to me that a certain level of maturity has been reached and that it is now time for me to consider using these devices.
I'd like to help, and I'm sure Ira Snyder will help too (most likely more so than me). I would like to obtain some SoC development kits so as to help with the SoC "experience" for end-users.
To aid in this development, I'd like some recommendations on what hardware to buy. I've included the list below the body of this email (to save cluttering the flow of this discussion). Its possible for me to obtain one or more of these boards.
Which ones are supported in mainline U-Boot and Linux? What will it take to make it easier for the end-user like myself?
Echoing earlier...There is good Linux support for the Altera Cyclone5 and Arria5 devkit and Terasic SoCkit from kernel.org.
I would like to be able to buy something like the Critical Link or Denx modules and simply plug them into my custom hardware, configure the FPGA fabric with whatever custom "magic" I need, have Ira develop a custom drive to that "magic" and just have things *WORK*. As an end-user, I don't want to have to pull a dozen patches off the mailing list to get a working system.
Altera's success in the SoC market depends on "getting it right" with respect to integration with the open-source community. That integration involves playing by the established set of rules. Wolfgang and his (creation and) support of U-Boot is of immeasurable value to the open-source community.
Altera developers, please follow Wolfgang's advice.
Wolfgang's advice is valuable and noted. However, it is in Altera's best interest that we have 1 central gathering point for all our opensource software support.
I maintain a linux-next git repo at rocketboards for patches that have been properly reviewed, and acked-by that are destined for kernel.org. The logic should follow that I(Altera) would do the same for u-boot patches at rocketboards that are destined for mainline u-boot at denx.
Thanks, Dinh
Cheers, Dave Hawkins, California Institute of Technology.
Cyclone V SoC Development Kit
http://www.altera.com/products/devkits/altera/kit-cyclone-v-soc.html
This is the main kit that most people are probably developing with. At $1,795 its pretty expensive, but I could request a couple of kits from the Altera University Program.
Arria V SoC kit
http://www.altera.com/products/devkits/altera/kit-arria-v-soc.html
At $3,495 this is also very expensive. This board still ships with ES (Engineering Sample), so I would not buy this yet.
Terasic/Arrow SOCKit
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=81...
At $299 this is pretty reasonable.
- SOC System-on-Modules
http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system...
eg, Critical Link MitySOM
http://www.criticallink.com/product/mitysom-5csx/
http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiM...
Each module is about $600 at Mouser.
Denx MCV board
These modules look reasonably priced.
The CriticalLink and Denx modules look suitable for my intended application, i.e., as the controller for a much larger FPGA board.
Wolfgang - feel free to advise me to use the Denx modules, and I'll take a more critical look at the data sheets to check they have the features I want to use.
Dear Dinh,
In message 5413667D.50001@opensource.altera.com you wrote:
Wolfgang's advice is valuable and noted. However, it is in Altera's best interest that we have 1 central gathering point for all our opensource software support.
Full agreement here. But I would like to point out that your point of view appears to be biased: U-Boot mainline is a community project, and the community is very much vendor-independent. So the question we're trying to solve here is not what is optimal for Altera, but what is optimal for the community.
As is, current mainline U-Boot is not really working well on most SoCFPGA systems. Progress is dissatisfactory slow. Marek volunteers to help out now, and you promise to chime in very soon. I see no conflict here. Let us create the u-boot-socfpga repository we need in any case, and agree with Marek as custodian until Vince has gathered enough reputation to relieve Marek. I talked to him - he is not clinging to that job, he just sees the need to get the current problems solved now, not in some uncertain future.
Please try to understand that this is totally unrelated to what you do at u-boot-socfpga-next - it does not influence your work there in any way. Ideally, your u-boot-socfpga-next and the mainline u-boot-socfpga repositories would be just redundant copies.
On the other hand, setting up u-boot-socfpga now allows the community to make some progress until you (rsp. Vince) start populating u-boot-socfpga-next and gather experience working with the community.
So it is actually in both the community's and Altera's best interest to get a mainline u-boot-socfpga set up without further delay.
Best regards,
Wolfgang Denk
Dear Wolfgang,
On Sat, 2014-09-13 at 00:37 +0200, ZY - wd wrote:
Dear Dinh,
In message 5413667D.50001@opensource.altera.com you wrote:
Wolfgang's advice is valuable and noted. However, it is in Altera's best interest that we have 1 central gathering point for all our opensource software support.
Full agreement here. But I would like to point out that your point of view appears to be biased: U-Boot mainline is a community project, and the community is very much vendor-independent. So the question we're trying to solve here is not what is optimal for Altera, but what is optimal for the community.
As is, current mainline U-Boot is not really working well on most SoCFPGA systems.
I would disagree on this. U-Boot with basic features is working well on Altera dev kit. I believe it works well for Pavel too as I recall from his emails. From his latest watchdog patch, seems he is able to boot to kernel too.
While for SPL, I would admit its bit slow. But almost all the essential drivers were there except the SDRAM. This has been dragged for long due to the legal discussion between GPL and BSD-3. I believe you are part of this length discussion too :) But this is resolved now after persuading our legal team. Hopefully we can send out the SDRAM patch soon.
Thanks Chin Liang
Hi!
Wolfgang's advice is valuable and noted. However, it is in Altera's best interest that we have 1 central gathering point for all our opensource software support.
Full agreement here. But I would like to point out that your point of view appears to be biased: U-Boot mainline is a community project, and the community is very much vendor-independent. So the question we're trying to solve here is not what is optimal for Altera, but what is optimal for the community.
As is, current mainline U-Boot is not really working well on most SoCFPGA systems.
I would disagree on this. U-Boot with basic features is working well on Altera dev kit. I believe it works well for Pavel too as I recall from his emails. From his latest watchdog patch, seems he is able to boot to kernel too.
I'd not characterize latest mainline u-boot as "working well". I hit some obscure problems (time running 1000x too fast, low memory not working, linux not starting) and was not able to get it working in reliable way.
In my eyes it was pretty predictable: when the port is without mmc and ethernet support, there's no surprise it bitrots.
Linux still does not reliably start for me :-(.
Now, don't spend too much time staring at [rfc] patch, there should be split up version later today.
While for SPL, I would admit its bit slow. But almost all the essential drivers were there except the SDRAM. This has been dragged for long due to the legal discussion between GPL and BSD-3. I believe you are part of this length discussion too :) But this is resolved now after persuading our legal team. Hopefully we can send out the SDRAM patch soon.
Good, so things are getting better. Pavel
Hi Dinh,
Up until now I have avoided any SoC development kits as I considered the software support to not have matured enough. I consider "mature" code to be code that I can checkout from mainline, where mainline is U-Boot via the Denx repos, and Linux via the Kernel repos.
For Linux, we have done a better job than u-boot. You should be able to have most of what you need from kernel.org for the Altera Devkits and Terasic SocKit board. The most important piece maybe the FPGA manager, otherwise the SOCFPGA platform is just any other A9 board.
The FPGA manager is in-flight:
Thanks, this is valuable and encouraging feedback.
For U-boot, the upstreaming process has been slow. I admit it, but it is very high on our to-do list.
One thing Altera needs to understand is that there are numerous developers out there that are willing to help. If the upstreaming process is slow, perhaps that is due to lack of openness? I'm not saying that is the case here, but its a consideration. There are plenty of people willing to help, and sometimes all it takes is asking :)
Freescale has done this forever, and I hold their processors and code in high regard.
I used to work at Freescale's doing the i.MX parts. I hope these were the processors you had in the mind?
We've been using the PowerPC products, but the iMX parts are very nice too, they just didn't happen to have the peripheral combo I needed.
Which ones are supported in mainline U-Boot and Linux? What will it take to make it easier for the end-user like myself?
Echoing earlier...There is good Linux support for the Altera Cyclone5 and Arria5 devkit and Terasic SoCkit from kernel.org.
Ok, that is good to know, thank-you.
Altera developers, please follow Wolfgang's advice.
Wolfgang's advice is valuable and noted. However, it is in Altera's best interest that we have 1 central gathering point for all our opensource software support.
I maintain a linux-next git repo at rocketboards for patches that have been properly reviewed, and acked-by that are destined for kernel.org. The logic should follow that I(Altera) would do the same for u-boot patches at rocketboards that are destined for mainline u-boot at denx.
As the maintainer of the U-Boot socfpga repository you would still have the level of control you want. The rocketboards repo would be a location that could be used to access a clone of the u-boot mainline, and as Wolfgang mentioned, your u-boot-socfpga-next development repo can be anywhere you want it.
Keep in mind that git is not centralized like subversion or CVS, so having a central git repo is really more of a "convention" than something required by the architecture. As an end-user of software, the "brand I trust" is U-Boot, so when I want the latest source for U-Boot, I go to the source. Rocketboards does not have any brand recognition for me, so its not a trusted source.
Keep in mind that Altera's track record with NIOS II and Linux support will cloud the judgement of many users. I never got to the point of trying uCLinux or Linux on NIOS II as I have never seen clean support for that processor architecture. That situation may have changed now, but the Altera NIOS II U-Boot and Linux brand was tarnished by poor initial support and openness.
Please do not take any of these comments as negative, or as a complaint that you are not doing your job, this is merely feedback from a third party that just wants to be able to "plug" an SoC into a system and have working U-Boot and Linux, so that I can concentrate on my own unique hardware/software layered upon that solid base.
The open-source community really appreciates Altera taking the time to listen and benefit from our help.
Cheers, Dave
Hi David,
On 9/13/14, 12:24 PM, David Hawkins wrote:
Hi Dinh,
Up until now I have avoided any SoC development kits as I considered the software support to not have matured enough. I consider "mature" code to be code that I can checkout from mainline, where mainline is U-Boot via the Denx repos, and Linux via the Kernel repos.
For Linux, we have done a better job than u-boot. You should be able to have most of what you need from kernel.org for the Altera Devkits and Terasic SocKit board. The most important piece maybe the FPGA manager, otherwise the SOCFPGA platform is just any other A9 board.
The FPGA manager is in-flight:
Thanks, this is valuable and encouraging feedback.
For U-boot, the upstreaming process has been slow. I admit it, but it is very high on our to-do list.
One thing Altera needs to understand is that there are numerous developers out there that are willing to help. If the upstreaming process is slow, perhaps that is due to lack of openness? I'm not saying that is the case here, but its a consideration. There are plenty of people willing to help, and sometimes all it takes is asking :)
Agreed. From day one of the SOCFPGA project, we(Altera's Linux/U-boot's development team have made a pledge to upstream as much support as possible and to be as open as possible. The thought behind rocketboards was also a central point of information for socfpga, that would include patches for linux and u-boot. We've established that for linux, and now need to do the same for u-boot.
Freescale has done this forever, and I hold their processors and code in high regard.
I used to work at Freescale's doing the i.MX parts. I hope these were the processors you had in the mind?
We've been using the PowerPC products, but the iMX parts are very nice too, they just didn't happen to have the peripheral combo I needed.
Which ones are supported in mainline U-Boot and Linux? What will it take to make it easier for the end-user like myself?
Echoing earlier...There is good Linux support for the Altera Cyclone5 and Arria5 devkit and Terasic SoCkit from kernel.org.
Ok, that is good to know, thank-you.
Altera developers, please follow Wolfgang's advice.
Wolfgang's advice is valuable and noted. However, it is in Altera's best interest that we have 1 central gathering point for all our opensource software support.
I maintain a linux-next git repo at rocketboards for patches that have been properly reviewed, and acked-by that are destined for kernel.org. The logic should follow that I(Altera) would do the same for u-boot patches at rocketboards that are destined for mainline u-boot at denx.
As the maintainer of the U-Boot socfpga repository you would still have the level of control you want. The rocketboards repo would be a location that could be used to access a clone of the u-boot mainline, and as Wolfgang mentioned, your u-boot-socfpga-next development repo can be anywhere you want it.
I think the point has shifted that Wolfgang wants to appoint an external entity to be the custodian for u-boot-socfpga-next. I contend that an in-house custodian(Altera employee) would do a much better job, have the information, and put Altera's best interest first in this job.
Keep in mind that git is not centralized like subversion or CVS, so having a central git repo is really more of a "convention" than something required by the architecture. As an end-user of software, the "brand I trust" is U-Boot, so when I want the latest source for U-Boot, I go to the source. Rocketboards does not have any brand recognition for me, so its not a trusted source.
Good point. This was the problem with the raspberry-pi for quite some time, but those guys have done a good job upstreaming the rpi support to mainline. Regarding the "brand I trust", what latest feature(s) of u-boot are you looking for on the socfpga that is not available downstream and is available in the mainline?
Keep in mind that Altera's track record with NIOS II and Linux support will cloud the judgement of many users. I never got to the point of trying uCLinux or Linux on NIOS II as I have never seen clean support for that processor architecture. That situation may have changed now, but the Altera NIOS II U-Boot and Linux brand was tarnished by poor initial support and openness.
Please see here: https://lkml.org/lkml/2014/9/8/139
Please do not take any of these comments as negative, or as a complaint that you are not doing your job, this is merely feedback from a third party that just wants to be able to "plug" an SoC into a system and have working U-Boot and Linux, so that I can concentrate on my own unique hardware/software layered upon that solid base.
The open-source community really appreciates Altera taking the time to listen and benefit from our help.
Your feedback is very valuable and as I've stated earlier, the Altera's Linux/U-boot team is committed to the community from day one. But as you've seen from the NIOS II past openness issue, Altera's core was not about openness. We've made good strides to convince the company that being part of the community is a very good thing. Heck, as you may have notice from our email address(opensource.altera.com). It's only taken us 2 years to get that.
Dinh
Dear Dinh,
In message 5415B6A7.9020102@gmail.com you wrote:
I think the point has shifted that Wolfgang wants to appoint an external entity to be the custodian for u-boot-socfpga-next.
You misunderstand me. It is not up to me to decide who the custodian shall be. This is a community decision, which in the past has always been based on a track record of previous work with the U-Boot community. It makes a lot of sense to handle this case in the same way.
I contend that an in-house custodian(Altera employee) would do a much better job, have the information, and put Altera's best interest first in this job.
Resources and interest are but one side; the other is experience of working with and being part of the community. Being custodian is a really trustworthy position - but trust cannot be assigned, it results from previous work here in the community.
Best regards,
Wolfgang Denk
Hi Dinh,
From day one of the SOCFPGA project, we(Altera's Linux/U-boot's development team have made a pledge to upstream as much support as possible and to be as open as possible. The thought behind rocketboards was also a central point of information for socfpga, that would include patches for linux and u-boot. We've established that for linux, and now need to do the same for u-boot.
That's great to hear.
As the maintainer of the U-Boot socfpga repository you would still have the level of control you want. The rocketboards repo would be a location that could be used to access a clone of the u-boot mainline, and as Wolfgang mentioned, your u-boot-socfpga-next development repo can be anywhere you want it.
I think the point has shifted that Wolfgang wants to appoint an external entity to be the custodian for u-boot-socfpga-next. I contend that an in-house custodian(Altera employee) would do a much better job, have the information, and put Altera's best interest first in this job.
Wolfgang's subsequent mails have clarified this point.
A "custodian" has nothing to do with ownership, its merely the person with a demonstrated skill for "caring" about code. No one has a problem with you being that custodian, but typically it is a position that is earned. So don't stress about it too much, personally, in your position, I would allow Marek to aid in getting an socfpga repo getting setup and cleaned up to make your life easier in the long run. If that aid involves him being listed as the maintainer for a month or so, and then you take over, its no big deal.
Why let Marek setup the repo? Well, he's likely much more familiar with U-Boot's standards, has lots of U-Boot contacts, and so he'll fix/clean up a whole bunch of stuff that would otherwise generate lots of needless mailing list traffic, and result in additional effort (and stress!) for you. So, let Marek do the hard work, and then buy him a beer (or send him some Altera toys) sometime when you get a chance to meet him.
Good point. This was the problem with the raspberry-pi for quite some time, but those guys have done a good job upstreaming the rpi support to mainline. Regarding the "brand I trust", what latest feature(s) of u-boot are you looking for on the socfpga that is not available downstream and is available in the mainline?
I'll let you know when I get an SoC board :)
Keep in mind that Altera's track record with NIOS II and Linux support will cloud the judgement of many users. I never got to the point of trying uCLinux or Linux on NIOS II as I have never seen clean support for that processor architecture. That situation may have changed now, but the Altera NIOS II U-Boot and Linux brand was tarnished by poor initial support and openness.
Please see here: https://lkml.org/lkml/2014/9/8/139
Great! But note that it has taken until Sept 2014 for this stuff to finally get resolved :)
Your feedback is very valuable and as I've stated earlier, the Altera's Linux/U-boot team is committed to the community from day one. But as you've seen from the NIOS II past openness issue, Altera's core was not about openness. We've made good strides to convince the company that being part of the community is a very good thing. Heck, as you may have notice from our email address(opensource.altera.com). It's only taken us 2 years to get that.
We all applaud your efforts in this, thanks! This will be a great help in getting more people to use the Altera SoC devices.
Cheers, Dave
Hi all,
Texas Instruments has recently realized that this is the way to go, and have invested significantly in this area - as demonstrated by Tom Rini. TI have dedicated a page to mainlining:
TI also has a very nice article in Electronic Products on the benefits of mainlining Linux ...
http://www.electronicproducts.com/Software/Development_Tools_and_Software/Th...
Altera would benefit from a similar philosophy.
Cheers, Dave
Hi Wolfgang,
On 09/11/2014 09:46 AM, Wolfgang Denk wrote:
Dear Michal,
In message 54112B64.5010104@monstr.eu you wrote:
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it.
Please don't get me wrong I am just trying to understand what happened.
We have MAINTAINERS file where we can simply add person who is responsible for specific SOC. I also believe that this is exactly reason why to have it.
From that file everybody can find out who should take the patches and and almost doesn't matter if git is at denx.de or somewhere else.
But still all ARM patches should go through our ARM custodian not directly to Tom.
get_maintainer.pl should also keep all interested people in the loop.
I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information.
Isn't that MAINTAINERS file already publicly available? Of course if you want to add the same information on wiki, I can't see any problem there. But creating separate repository for every SoC in u-boot seems to me just too much.
In socfpga case I think there are guys from Altera who maintain it.
Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this.
Definitely I also really appreciate that Marek volunteers to be responsible for socfpga. But that means that guys who are responsible for socfpga failed and they are not responding for patches which others are sending to mailing list for review. I am not closely following them but did this really happen?
If they don't want to maintain their socfpga in mainline and Marek wants to do it I will definitely support Marek in this new possition to get things done properly but also I just want to make sure that this is really happen and isn't it just the part of misunderstanding how u-boot community is working.
As far as I am concerned, I support both Marek's and Masahiro's requests.
@ Marek and Masahiro: if we reach an agreement to create such repos, please send me your SSH public keys that shall be used for these. Also, what should the names be - u-boot-socfpga ? And u-boot-uniphier ? [But is there not a chance that Pana- sonic might have other SoCs that might be mainlines? So maybe we should use u-boot-panasonic instead?]
If they want to have separate repository because they think that it is better then their current one then sure why not to create them.
Having arm SOC sub maintainers is definitely good concept but I am just not sure that creating separate repository fully solve this.
Thanks, Michal
Dear Michal,
In message 541334D0.80109@monstr.eu you wrote:
But creating separate repository for every SoC in u-boot seems to me just too much.
We're not talking about one repo for every SoC here.
Definitely I also really appreciate that Marek volunteers to be responsible for socfpga. But that means that guys who are responsible for socfpga failed and they are not responding for patches which others are sending to mailing list for review. I am not closely following them but did this really happen?
I think the problem is that so far nobody feels responsible for systematically mainlining the code. There are some patches here and there, but usually you cannot build a useful and working U-Boot image from the existing mainline code.
If they don't want to maintain their socfpga in mainline and Marek wants to do it I will definitely support Marek in this new possition to get things done properly but also I just want to make sure that this is really happen and isn't it just the part of misunderstanding how u-boot community is working.
Probably both.
Having arm SOC sub maintainers is definitely good concept but I am just not sure that creating separate repository fully solve this.
You are right - the repository is just one necessary step. A custodian who knows how the community works and who is willing to collect patches and synchronize efforts is also needed - this is where Marek volunteered for now. If someone from Altera is willing to take over, such a switch would be trivial to perform.
Best regards,
Wolfgang Denk
On Thursday, September 11, 2014 at 06:56:04 AM, Michal Simek wrote:
Hi,
On 09/11/2014 05:09 AM, Masahiro Yamada wrote:
On Thu, 11 Sep 2014 01:33:20 +0200
Marek Vasut marex@denx.de wrote:
Hello,
I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place.
Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes.
That would be faster and would not disturb Albert.
I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that.
WD already answered that part, so I'll skip this.
Alberts know that and it is working quite well. It is enough to talk to him and that's it. In socfpga case I think there are guys from Altera who maintain it.
That's not quite the case, that's why I stepped up. Again, WD explained the rocketboards situation, but we need to improve on the mainline push and this repository should help I hope.
Best regards, Marek Vasut
participants (13)
-
Albert ARIBAUD -
Chin Liang See -
David Hawkins -
Dinh Nguyen -
Dinh Nguyen -
Marek Vasut -
Masahiro YAMADA -
Masahiro Yamada
-
Michael Trimarchi -
Michal Simek -
Pavel Machek -
Tom Rini -
Wolfgang Denk