[U-Boot] u-boot-socfpga repository

[U-Boot] u-boot-socfpga repository

[Marek Vasut]

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

[U-Boot] u-boot-socfpga repository

[Masahiro Yamada]

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

[U-Boot] u-boot-socfpga repository

[Michal Simek]

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

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140911/9aaed9c9/attachment.pgp>

[U-Boot] u-boot-socfpga repository

[Masahiro Yamada]

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

[U-Boot] U-Boot panasonic repo

[Marek Vasut]

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

[U-Boot] U-Boot panasonic repo

[Michal Simek]

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

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140918/28da4c5b/attachment.pgp>

[U-Boot] U-Boot panasonic repo

[Marek Vasut]

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

[U-Boot] U-Boot panasonic repo

[Michal Simek]

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

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140918/3d706365/attachment.pgp>

[U-Boot] U-Boot panasonic repo

[Masahiro Yamada]

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

[U-Boot] U-Boot panasonic repo

[Albert ARIBAUD]

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

[U-Boot] U-Boot panasonic repo

[Masahiro YAMADA]

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

[U-Boot] U-Boot panasonic repo

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Wisdom is one of the few things that looks bigger the further away it
is.                               - Terry Pratchett, _Witches Abroad_

[U-Boot] U-Boot panasonic repo

[Masahiro Yamada]

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

[U-Boot] U-Boot panasonic repo

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
        "That we but teach bloody instructions,
        which, being taught, return to plague the inventor..."

[U-Boot] U-Boot panasonic repo

[Masahiro YAMADA]

Hi.


I am trying to push to the newly-created u-boot-uniphier repo
but I am in trouble.


masahiro at oscar:~/workspace/u-boot-uniphier$ git push
ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git
X11 forwarding request failed on channel 0
Total 0 (delta 0), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree
inconsistent
remote: error: with what you pushed, and will require 'git reset
--hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to
'ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git'



According to this error message, it looks like the u-boot-uniphier on
the denx server
has been created as a non-bare repository, right?

The message also recommended to do "git config receive.denyCurrentBranch ignore"
on the remote repo, but I seems impossible for me to do that.

Someone, give me a tip if I am missing something.

Perhaps, the repo should be re-created as a bare one?
Or could you add "receive.denyCurrentBranch ignore" configuration,  Wolfgang?



-- 
Best Regards
Masahiro Yamada

[U-Boot] U-Boot panasonic repo

[Wolfgang Denk]

Dear Masahiro,

In message <CAMhH57Rx8VLZ9fL6OXeyJMWwnSKTg36dTERENm0YVQcLPRuqVg@mail.gmail.com> you wrote:
> 
> I am trying to push to the newly-created u-boot-uniphier repo
> but I am in trouble.
> 
> masahiro at oscar:~/workspace/u-boot-uniphier$ git push ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git
...
> remote: error: By default, updating the current branch in a non-bare repository
> remote: error: is denied, because it will make the index and work tree
> inconsistent

I recommend to always explicitly tell which branch you are trying to
push where.

For example, if your local branch which you are preparing for a pull
request is "for-upstream", then your push command would look like
this:

git push ssh://gu-uniphier at git.denx.de/u-boot-uniphier for-upstream:master

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is your destiny.                                     - Darth Vader

[U-Boot] U-Boot panasonic repo

[Masahiro YAMADA]

Hi Wolfgang,

2014-09-27 22:00 GMT+09:00 Wolfgang Denk <wd@denx.de>:
> Dear Masahiro,
>
> In message <CAMhH57Rx8VLZ9fL6OXeyJMWwnSKTg36dTERENm0YVQcLPRuqVg@mail.gmail.com> you wrote:
>>
>> I am trying to push to the newly-created u-boot-uniphier repo
>> but I am in trouble.
>>
>> masahiro at oscar:~/workspace/u-boot-uniphier$ git push ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git
> ...
>> remote: error: By default, updating the current branch in a non-bare repository
>> remote: error: is denied, because it will make the index and work tree
>> inconsistent
>
> I recommend to always explicitly tell which branch you are trying to
> push where.
>
> For example, if your local branch which you are preparing for a pull
> request is "for-upstream", then your push command would look like
> this:
>
> git push ssh://gu-uniphier at git.denx.de/u-boot-uniphier for-upstream:master
>



I am afraid your recommendation won't solve the problem I am having now.

I can create a new branch on the remote u-boot-uniphier.git
but I cannot update the master branch.


$ git --version
git version 1.9.1
masahiro at oscar:~/workspace/u-boot-uniphier$ git branch
* master
masahiro at oscar:~/workspace/u-boot-uniphier$ git describe
v2014.10-rc2-274-gf9860cf
masahiro at oscar:~/workspace/u-boot-uniphier$ git push
ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git master:master
X11 forwarding request failed on channel 0
Total 0 (delta 0), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree
inconsistent
remote: error: with what you pushed, and will require 'git reset
--hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to
'ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git'
masahiro at oscar:~/workspace/u-boot-uniphier$ git checkout -b for-upstream
Switched to a new branch 'for-upstream'
masahiro at oscar:~/workspace/u-boot-uniphier$ git branch
* for-upstream
  master
masahiro at oscar:~/workspace/u-boot-uniphier$ git push
ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git for-upstream:master
X11 forwarding request failed on channel 0
Total 0 (delta 0), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree
inconsistent
remote: error: with what you pushed, and will require 'git reset
--hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git
 ! [remote rejected] for-upstream -> master (branch is currently checked out)
error: failed to push some refs to
'ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git'
masahiro at oscar:~/workspace/u-boot-uniphier$ git push
ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git
for-upstream:for-upstream
X11 forwarding request failed on channel 0
Total 0 (delta 0), reused 0 (delta 0)
To ssh://gu-uniphier at git.denx.de/u-boot-uniphier.git
 * [new branch]      for-upstream -> for-upstream



The error message is saying that the remote u-boot-uniphier is a
non-bare repository
and the 'master' branch is already checked out (commit
9170818a4e004af7893fa0113f6e5b4afafded55).
That is why I cannot update the master branch, I think.


When I create a repo just for pushing to and fetching from, I use
"--bare" option.

Why not for the u-boot-uniphier.git on git.denx.de ?

Is anyone doing his work on that repo?



-- 
Best Regards
Masahiro Yamada

[U-Boot] U-Boot panasonic repo

[Wolfgang Denk]

Dear Masahiro,

In message <CAMhH57Tp302tcPwTFPu5stNzcBH491t8tDLEESb-7XhMzuBU2w@mail.gmail.com> you wrote:
> 
> I can create a new branch on the remote u-boot-uniphier.git
> but I cannot update the master branch.

Please try again now.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The use of Microsoft crippleware systems is a sin that  carries  with
it its own punishment.
         -- Tom Christiansen in <6bo3fr$pj8$5@csnews.cs.colorado.edu>

[U-Boot] U-Boot panasonic repo

[Masahiro YAMADA]

Hi Wolfgang,


2014-09-28 0:57 GMT+09:00 Wolfgang Denk <wd@denx.de>:
> Dear Masahiro,
>
> In message <CAMhH57Tp302tcPwTFPu5stNzcBH491t8tDLEESb-7XhMzuBU2w@mail.gmail.com> you wrote:
>>
>> I can create a new branch on the remote u-boot-uniphier.git
>> but I cannot update the master branch.
>
> Please try again now.


Everything looks working fine now.

Thank you!!



-- 
Best Regards
Masahiro Yamada

[U-Boot] u-boot-socfpga repository

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
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] u-boot-socfpga repository

[Pavel Machek]

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] u-boot-socfpga repository

[Marek Vasut]

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

[U-Boot] u-boot-socfpga repository

[Dinh Nguyen]

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

[U-Boot] u-boot-socfpga repository

[Marek Vasut]

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

[U-Boot] u-boot-socfpga repository

[Pavel Machek]

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] u-boot-socfpga repository

[Chin Liang See]

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

[U-Boot] u-boot-socfpga repository

[Chin Liang See]

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

> 

[U-Boot] u-boot-socfpga repository

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140923/48e14fa3/attachment.pgp>

[U-Boot] u-boot-socfpga repository

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What is tolerance? -- it is the consequence of humanity. We  are  all
formed  of frailty and error; let us pardon reciprocally each other's
folly -- that is the first law of nature.                  - Voltaire

[U-Boot] u-boot-socfpga repository

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140923/12204f49/attachment.pgp>

[U-Boot] u-boot-socfpga repository

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You see things; and you say ``Why?'' But I dream  things  that  never
were; and I say ``Why not?''
       - George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1

[U-Boot] u-boot-socfpga repository

[Marek Vasut]

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

[U-Boot] u-boot-socfpga repository

[Dinh Nguyen]

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 at 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot-socfpga repository

[Marek Vasut]

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

[U-Boot] u-boot-socfpga repository

[Dinh Nguyen]

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

[U-Boot] u-boot-socfpga repository

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140911/d93443eb/attachment.pgp>

[U-Boot] u-boot-socfpga repository

[Dinh Nguyen]

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

[U-Boot] u-boot-socfpga repository

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
C makes it easy for you to shoot yourself in the foot. C++ makes that
harder, but when you do, it blows away your whole leg.
                                                 -- Bjarne Stroustrup

[U-Boot] u-boot-socfpga repository

[Dinh Nguyen]

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

[U-Boot] u-boot-socfpga repository

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You get a wonderful view from the point of no return.
                                    - Terry Pratchett, _Making_Money_

[U-Boot] u-boot-socfpga repository

[Dinh Nguyen]

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

[U-Boot] u-boot-socfpga repository

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Only in our dreams we are free.  The rest of the time we need  wages.
                                    - Terry Pratchett, _Wyrd Sisters_

[U-Boot] u-boot-socfpga repository

[Dinh Nguyen]

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

[U-Boot] u-boot-socfpga repository

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"In the long run, every program becomes rococo, and then rubble."
- Alan Perlis

[U-Boot] u-boot-socfpga repository

[Dinh Nguyen]

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

[U-Boot] u-boot-socfpga repository

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140914/045ea1dc/attachment.pgp>

[U-Boot] u-boot-socfpga repository

[Chin Liang See]

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

[U-Boot] u-boot-socfpga repository

[Marek Vasut]

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

[U-Boot] u-boot-socfpga repository

[Chin Liang See]

Dear Marex,

On Mon, 2014-09-15 at 03:27 +0200, marex at 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

[U-Boot] u-boot-socfpga repository

[Marek Vasut]

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

[U-Boot] u-boot-socfpga repository

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ernest asks Frank how long he has been working for the company.
        "Ever since they threatened to fire me."

[U-Boot] u-boot-socfpga repository

[Michael Trimarchi]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot-socfpga repository

[David Hawkins]

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=816

    At $299 this is pretty reasonable.

4. SOC System-on-Modules

 
http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system-module.html

    eg, Critical Link MitySOM

    http://www.criticallink.com/product/mitysom-5csx/

 
http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiMZZMvtrnhC60i%252bOnQkBUtKjKom2RbBJy3SVoI%3d

    Each module is about $600 at Mouser.

5. Denx MCV board

    http://www.denx-cs.de/?q=MCV

    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] u-boot-socfpga repository

[Michael Trimarchi]

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

> ------------------------------------------------------------------
>
> 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=816
>
>    At $299 this is pretty reasonable.
>
> 4. SOC System-on-Modules
>
>
>
http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system-module.html
>
>    eg, Critical Link MitySOM
>
>    http://www.criticallink.com/product/mitysom-5csx/
>
>
>
http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiMZZMvtrnhC60i%252bOnQkBUtKjKom2RbBJy3SVoI%3d
>
>    Each module is about $600 at Mouser.
>
> 5. Denx MCV board
>
>    http://www.denx-cs.de/?q=MCV
>
>    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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot-socfpga repository

[David Hawkins]

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

[U-Boot] u-boot-socfpga repository

[Michael Trimarchi]

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
>

[U-Boot] u-boot-socfpga repository

[Dinh Nguyen]

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.
> 
> ------------------------------------------------------------------
> 
> 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=816
> 
>    At $299 this is pretty reasonable.
> 
> 4. SOC System-on-Modules
> 
> 
> http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system-module.html
> 
> 
>    eg, Critical Link MitySOM
> 
>    http://www.criticallink.com/product/mitysom-5csx/
> 
> 
> http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiMZZMvtrnhC60i%252bOnQkBUtKjKom2RbBJy3SVoI%3d
> 
> 
>    Each module is about $600 at Mouser.
> 
> 5. Denx MCV board
> 
>    http://www.denx-cs.de/?q=MCV
> 
>    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] u-boot-socfpga repository

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Well, the way I see it, logic is only a way of being ignorant by num-
bers.                                 - Terry Pratchett, _Small Gods_

[U-Boot] u-boot-socfpga repository

[Chin Liang See]

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

[U-Boot] mainline u-boot on socfpga

[Pavel Machek]

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] u-boot-socfpga repository

[David Hawkins]

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:
>
> https://lkml.org/lkml/2014/8/1/517

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

[U-Boot] u-boot-socfpga repository

[Dinh Nguyen]

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:
>>
>> https://lkml.org/lkml/2014/8/1/517
> 
> 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

[U-Boot] u-boot-socfpga repository

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In the beginning, there was nothing, which exploded.
                                - Terry Pratchett, _Lords and Ladies_

[U-Boot] u-boot-socfpga repository

[David Hawkins]

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

[U-Boot] u-boot-socfpga repository

[David Hawkins]

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:
>
> http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page

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/The_benefits_of_Mainline_Linux_and_the_mindset_of_upstream_development.aspx

Altera would benefit from a similar philosophy.

Cheers,
Dave

[U-Boot] u-boot-socfpga repository

[Michal Simek]

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

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140912/0b3505b8/attachment.pgp>

[U-Boot] u-boot-socfpga repository

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Build a system that even a fool can use and only a fool will want  to
use it.

[U-Boot] u-boot-socfpga repository

[Marek Vasut]

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