[U-Boot-Users] Please pull u-boot-mpc83xx.git mpc83xx branch into testing
Wolfgang,
Please pull the mpc83xx branch into your testing tree:
git pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
to get the following changes (essentially support for the MPC837xEMDS board):
Dave Liu (6): mpc83xx: Add the support of MPC837x SoC mpc83xx: Add the support of MPC8315E SoC mpc83xx: Add the support of MPC837xEMDS board mpc83xx: Add the MPC837xEMDS board readme mpc83xx: add MAINTAINER and MAKEALL entries for the mpc837xemds mpc83xx: update the CREDITS and MAINTAINERS
CREDITS | 5 + MAINTAINERS | 2 + MAKEALL | 1 + Makefile | 10 + board/freescale/mpc837xemds/Makefile | 50 +++ board/freescale/mpc837xemds/config.mk | 28 ++ board/freescale/mpc837xemds/mpc837xemds.c | 144 +++++++ board/freescale/mpc837xemds/pci.c | 65 +++ cpu/mpc83xx/cpu.c | 36 ++- cpu/mpc83xx/cpu_init.c | 6 +- cpu/mpc83xx/spd_sdram.c | 7 +- cpu/mpc83xx/speed.c | 201 ++++++++-- doc/README.mpc837xemds | 104 +++++ drivers/tsec.c | 10 + include/asm-ppc/global_data.h | 15 +- include/asm-ppc/immap_83xx.h | 145 +++++++- include/configs/MPC837XEMDS.h | 605 +++++++++++++++++++++++++++++ include/mpc83xx.h | 261 +++++++++++-- 18 files changed, 1635 insertions(+), 60 deletions(-) create mode 100644 board/freescale/mpc837xemds/Makefile create mode 100644 board/freescale/mpc837xemds/config.mk create mode 100644 board/freescale/mpc837xemds/mpc837xemds.c create mode 100644 board/freescale/mpc837xemds/pci.c create mode 100644 doc/README.mpc837xemds create mode 100644 include/configs/MPC837XEMDS.h
Thanks,
Kim
On 9/24/07, Kim Phillips kim.phillips@freescale.com wrote:
Wolfgang,
Please pull the mpc83xx branch into your testing tree:
git pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
to get the following changes (essentially support for the MPC837xEMDS board):
NOT YET PLEASE!!! :-)
The config rework patches are scheduled to go into -testing before anything else in preparation for the next merge window. There are some invasive makefile changes involved in the config rework that you might need to rebase/merge on top of.
Cheers, g.
In message 20070924151901.61717d5d.kim.phillips@freescale.com you wrote:
Please pull the mpc83xx branch into your testing tree:
git pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
Sorry, but no.
There is no merge window open at the moment.
Best regards,
Wolfgang Denk
On Mon, 24 Sep 2007 22:39:22 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20070924151901.61717d5d.kim.phillips@freescale.com you wrote:
Please pull the mpc83xx branch into your testing tree:
git pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
Sorry, but no.
There is no merge window open at the moment.
ok, let me understand how you want this to work.
my original intent was for you to pull 837x support into your /testing/ tree so that gcl's mass-rename scripts could do their magic on the 837x board port too.
but it sounds like you want me to hold on to new 83xx boards/features until you make a final (non-rc) release? Sounds like I should be asking gcl to share his scripts then.
Kim
On 9/24/07, Kim Phillips kim.phillips@freescale.com wrote:
On Mon, 24 Sep 2007 22:39:22 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20070924151901.61717d5d.kim.phillips@freescale.com you wrote:
Please pull the mpc83xx branch into your testing tree:
git pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
Sorry, but no.
There is no merge window open at the moment.
ok, let me understand how you want this to work.
my original intent was for you to pull 837x support into your /testing/ tree so that gcl's mass-rename scripts could do their magic on the 837x board port too.
but it sounds like you want me to hold on to new 83xx boards/features until you make a final (non-rc) release? Sounds like I should be asking gcl to share his scripts then.
I'll definitely share my scripts once I've got the working. :-) As it stands right now, I might have to back off some of the mass renames for the next merge window. It's a complex job, and I want to be absolutely sure that I do it in a safe way.
Regardless, I'll be posting my changes to the list for comments *before* I ask Wolfgang to merge them into testing.
Cheers, g.
In message 20070924161309.9f14b16e.kim.phillips@freescale.com you wrote:
There is no merge window open at the moment.
ok, let me understand how you want this to work.
my original intent was for you to pull 837x support into your /testing/ tree so that gcl's mass-rename scripts could do their magic on the 837x board port too.
No, that will not work. You would move Grant's base under his feet.
but it sounds like you want me to hold on to new 83xx boards/features until you make a final (non-rc) release? Sounds like I should be asking gcl to share his scripts then.
No again. Please just wait until we have a somehwat stable base in testing, and Grant has applied his patches there. Then use *this* as base for any new submissions, which you then should post in the merge window.
Best regards,
Wolfgang Denk
On Mon, 24 Sep 2007 23:52:29 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20070924161309.9f14b16e.kim.phillips@freescale.com you wrote:
There is no merge window open at the moment.
ok, let me understand how you want this to work.
my original intent was for you to pull 837x support into your /testing/ tree so that gcl's mass-rename scripts could do their magic on the 837x board port too.
No, that will not work. You would move Grant's base under his feet.
this goes both ways. True, Grant's work is more intrusive, but that just means that all work that is or can be affected by it be staged in a single common tree. My understanding is you have designated the -testing tree for this particular purpose.
but it sounds like you want me to hold on to new 83xx boards/features until you make a final (non-rc) release? Sounds like I should be asking gcl to share his scripts then.
No again. Please just wait until we have a somehwat stable base in testing, and Grant has applied his patches there. Then use *this* as base for any new submissions, which you then should post in the merge window.
It sounds like you're suggesting everyone halt all new development indefinitely. Please clarify.
Kim
On 9/24/07, Kim Phillips kim.phillips@freescale.com wrote:
On Mon, 24 Sep 2007 23:52:29 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20070924161309.9f14b16e.kim.phillips@freescale.com you wrote:
There is no merge window open at the moment.
ok, let me understand how you want this to work.
my original intent was for you to pull 837x support into your /testing/ tree so that gcl's mass-rename scripts could do their magic on the 837x board port too.
No, that will not work. You would move Grant's base under his feet.
this goes both ways. True, Grant's work is more intrusive, but that just means that all work that is or can be affected by it be staged in a single common tree. My understanding is you have designated the -testing tree for this particular purpose.
I don't think that's quite true. In the last merge window, -testing got used to stage changes for the merge window with the least possible impact. In that case, it was Jon's CMD_* changes which needed to go in first.
It makes total sense to stage changes in the custodian trees, but Wolfgang retains the right to decide what order those changes get staged into -testing, and also to request custodians to merge/rebase/retest before pulling their tree.
but it sounds like you want me to hold on to new 83xx boards/features until you make a final (non-rc) release? Sounds like I should be asking gcl to share his scripts then.
No again. Please just wait until we have a somehwat stable base in testing, and Grant has applied his patches there. Then use *this* as base for any new submissions, which you then should post in the merge window.
It sounds like you're suggesting everyone halt all new development indefinitely. Please clarify.
Not at all! It is not a suggestion to halt development; but it is a warning that custodians need to do either a rebase or a merge before it is pulled when the window opens (or before Wolfgang chooses to pull them into -testing).
Besides; if I come up with a set of changes that will make a merge or rebase absolutely impossible, I'm sure Wolfgang will tell me what I can do with my patchset. :-)
Cheers, g.
On Mon, 24 Sep 2007 16:47:58 -0600 "Grant Likely" grant.likely@secretlab.ca wrote:
On 9/24/07, Kim Phillips kim.phillips@freescale.com wrote:
On Mon, 24 Sep 2007 23:52:29 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20070924161309.9f14b16e.kim.phillips@freescale.com you wrote:
There is no merge window open at the moment.
ok, let me understand how you want this to work.
my original intent was for you to pull 837x support into your /testing/ tree so that gcl's mass-rename scripts could do their magic on the 837x board port too.
No, that will not work. You would move Grant's base under his feet.
this goes both ways. True, Grant's work is more intrusive, but that just means that all work that is or can be affected by it be staged in a single common tree. My understanding is you have designated the -testing tree for this particular purpose.
I don't think that's quite true. In the last merge window, -testing got used to stage changes for the merge window with the least possible impact. In that case, it was Jon's CMD_* changes which needed to go in first.
Jon's CMD_* changes were performed in stages, with boards being added in between. Sure, after each phase, things inevitably broke, and they were promptly fixed up again, by him and others. Isn't that how your Kconfig changes are going to work (in phases)?
It makes total sense to stage changes in the custodian trees, but Wolfgang retains the right to decide what order those changes get staged into -testing, and also to request custodians to merge/rebase/retest before pulling their tree.
sure, and I can do that, I just wasn't aware of existing blockage. I would have expected blockage to occur between the time you submit patches to the mailing list and when WD applies them to his tree.
I just want your (and others') /subsequent/ patches to include 837x code, so I, and other custodians btw, don't have to duplicate your work unnecessarily and keep on having to play catch up. But it sounds like you're not going to do it in phases, or, at least the phases are going to be clearly marked with releases 1.3.[123]?
but it sounds like you want me to hold on to new 83xx boards/features until you make a final (non-rc) release? Sounds like I should be asking gcl to share his scripts then.
No again. Please just wait until we have a somehwat stable base in testing, and Grant has applied his patches there. Then use *this* as base for any new submissions, which you then should post in the merge window.
It sounds like you're suggesting everyone halt all new development indefinitely. Please clarify.
Not at all! It is not a suggestion to halt development; but it is a warning that custodians need to do either a rebase or a merge before it is pulled when the window opens (or before Wolfgang chooses to pull them into -testing).
What most concerns me here is the indefiniteness of the situation. I think the process can be made more granular (and therefore efficient, without WD having to deny pull requests), but I'll wait and see how things go.
Besides; if I come up with a set of changes that will make a merge or rebase absolutely impossible, I'm sure Wolfgang will tell me what I can do with my patchset. :-)
yeah - we'll see :)
Kim
On 9/25/07, Kim Phillips kim.phillips@freescale.com wrote:
On Mon, 24 Sep 2007 16:47:58 -0600 "Grant Likely" grant.likely@secretlab.ca wrote:
On 9/24/07, Kim Phillips kim.phillips@freescale.com wrote:
On Mon, 24 Sep 2007 23:52:29 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20070924161309.9f14b16e.kim.phillips@freescale.com you wrote:
There is no merge window open at the moment.
ok, let me understand how you want this to work.
my original intent was for you to pull 837x support into your /testing/ tree so that gcl's mass-rename scripts could do their magic on the 837x board port too.
No, that will not work. You would move Grant's base under his feet.
this goes both ways. True, Grant's work is more intrusive, but that just means that all work that is or can be affected by it be staged in a single common tree. My understanding is you have designated the -testing tree for this particular purpose.
I don't think that's quite true. In the last merge window, -testing got used to stage changes for the merge window with the least possible impact. In that case, it was Jon's CMD_* changes which needed to go in first.
Jon's CMD_* changes were performed in stages, with boards being added in between. Sure, after each phase, things inevitably broke, and they were promptly fixed up again, by him and others. Isn't that how your Kconfig changes are going to work (in phases)?
It makes total sense to stage changes in the custodian trees, but Wolfgang retains the right to decide what order those changes get staged into -testing, and also to request custodians to merge/rebase/retest before pulling their tree.
sure, and I can do that, I just wasn't aware of existing blockage. I would have expected blockage to occur between the time you submit patches to the mailing list and when WD applies them to his tree.
I just want your (and others') /subsequent/ patches to include 837x code, so I, and other custodians btw, don't have to duplicate your work unnecessarily and keep on having to play catch up. But it sounds like you're not going to do it in phases, or, at least the phases are going to be clearly marked with releases 1.3.[123]?
Yes, the phases are going to be on the release marks. I have no intention of getting everything in by 1.3.1.
- Conditional compilation will definitely be ready and I hope will go in. This is the change I'm most concerned about being merged first because of the merge conflicts which will occur in the Makefiles and all the changes are done manually. These changes are *almost* ready. I've got a couple of board ports which are still not compiling correctly that need to be fixed, then I'll post the patch set (in the next day or so)
- Mass macro renames might go in for 1.3.1; but I need to test those changes up the wazo before I post them. Most likely I'll have a script which automates this change, which means it can either go in before or at the end of the merge window.
- I'm not even going to attempt migration to kconfig until 1.3.2 or 1.3.3.
Cheers, g.
In message 20070924161309.9f14b16e.kim.phillips@freescale.com you wrote:
On Mon, 24 Sep 2007 22:39:22 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20070924151901.61717d5d.kim.phillips@freescale.com you wrote:
Please pull the mpc83xx branch into your testing tree:
git pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
Sorry, but no.
There is no merge window open at the moment.
ok, let me understand how you want this to work.
my original intent was for you to pull 837x support into your /testing/ tree so that gcl's mass-rename scripts could do their magic on the 837x board port too.
but it sounds like you want me to hold on to new 83xx boards/features until you make a final (non-rc) release? Sounds like I should be asking gcl to share his scripts then.
Kim
Dear Wolfgang,
How about these patch? These patch really are holden for long time, :) two month.
Could you pick up these patch to main tree before you release the u-boot-1.3.0?
Thank you very much! Dave
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Phillips Kim-R1AAHA Sent: 2007?9?25? 4:19 AM To: Wolfgang Denk Cc: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] Please pull u-boot-mpc83xx.git mpc83xx branch intotesting
Wolfgang,
Please pull the mpc83xx branch into your testing tree:
git pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
to get the following changes (essentially support for the MPC837xEMDS board):
Dave Liu (6): mpc83xx: Add the support of MPC837x SoC mpc83xx: Add the support of MPC8315E SoC mpc83xx: Add the support of MPC837xEMDS board mpc83xx: Add the MPC837xEMDS board readme mpc83xx: add MAINTAINER and MAKEALL entries for the mpc837xemds mpc83xx: update the CREDITS and MAINTAINERS
CREDITS | 5 + MAINTAINERS | 2 + MAKEALL | 1 + Makefile | 10 + board/freescale/mpc837xemds/Makefile | 50 +++ board/freescale/mpc837xemds/config.mk | 28 ++ board/freescale/mpc837xemds/mpc837xemds.c | 144 +++++++ board/freescale/mpc837xemds/pci.c | 65 +++ cpu/mpc83xx/cpu.c | 36 ++- cpu/mpc83xx/cpu_init.c | 6 +- cpu/mpc83xx/spd_sdram.c | 7 +- cpu/mpc83xx/speed.c | 201 ++++++++-- doc/README.mpc837xemds | 104 +++++ drivers/tsec.c | 10 + include/asm-ppc/global_data.h | 15 +- include/asm-ppc/immap_83xx.h | 145 +++++++- include/configs/MPC837XEMDS.h | 605 +++++++++++++++++++++++++++++ include/mpc83xx.h | 261 +++++++++++-- 18 files changed, 1635 insertions(+), 60 deletions(-) create mode 100644 board/freescale/mpc837xemds/Makefile create mode 100644 board/freescale/mpc837xemds/config.mk create mode 100644 board/freescale/mpc837xemds/mpc837xemds.c create mode 100644 board/freescale/mpc837xemds/pci.c create mode 100644 doc/README.mpc837xemds create mode 100644 include/configs/MPC837XEMDS.h
Thanks,
Kim
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
On 11/18/07, Liu Dave DaveLiu@freescale.com wrote:
Dear Wolfgang,
How about these patch? These patch really are holden for long time, :) two month.
Could you pick up these patch to main tree before you release the u-boot-1.3.0?
Thank you very much! Dave
The tree is only open for bug fixes at the moment. New feature patches (such as these SoC and board support patches) need to wait for the next merge window.
Cheers, g.
No, I saw some drivers was merged at this moment.
I don't know why we need hold one patch for so much long time?
Do you have some difficult to handle somethings?
AFAIK, it is easier to merge some features to kernel than u-boot. I noticed that in this year the u-boot quality is sliping than one year ago.
I suggest we need make more testing before we do large changes. such as, consolidate driver directory and relocation stuff.
Thanks, Dave
-----Original Message----- From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely Sent: 2007?11?19? 2:57 PM To: Liu Dave Cc: Phillips Kim; Wolfgang Denk; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Please pull u-boot-mpc83xx.git mpc83xx branch intotesting
On 11/18/07, Liu Dave DaveLiu@freescale.com wrote:
Dear Wolfgang,
How about these patch? These patch really are holden for long time, :) two month.
Could you pick up these patch to main tree before you release the u-boot-1.3.0?
Thank you very much! Dave
The tree is only open for bug fixes at the moment. New feature patches (such as these SoC and board support patches) need to wait for the next merge window.
Cheers, g.
-- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely@secretlab.ca (403) 399-0195
Hi Dave,
On Monday 19 November 2007, Liu Dave wrote:
No, I saw some drivers was merged at this moment.
Which ones? This should not have happened.
I don't know why we need hold one patch for so much long time?
You are right, the last release cycles took quite long. But I am wondering, did Kim pull your changes into his 83xx custodian repository and ask Wolfgang to pull from it?
Do you have some difficult to handle somethings?
AFAIK, it is easier to merge some features to kernel than u-boot. I noticed that in this year the u-boot quality is sliping than one year ago.
I have a different observation here. From my point of view, we are doing quite good with all the new custodians in place. It could work better of course, and we are all still learning. But I think we are on the "right track".
Please note that this release cycle mechanism is still new to U-Boot. So hopefully the next cycles will be "less painful".
I suggest we need make more testing before we do large changes. such as, consolidate driver directory and relocation stuff.
This "relocation bug" has been in the master git repository for quite a while now. Nobody complained about it until a few weeks ago.
And yes, please help doing more testing. :)
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
On Mon, 19 Nov 2007 08:43:21 +0100 Stefan Roese sr@denx.de wrote:
Hi Dave,
On Monday 19 November 2007, Liu Dave wrote:
No, I saw some drivers was merged at this moment.
Which ones? This should not have happened.
I don't know why we need hold one patch for so much long time?
You are right, the last release cycles took quite long. But I am wondering, did Kim pull your changes into his 83xx custodian repository and ask Wolfgang to pull from it?
I'm maintaining mpc837x support in the mpc83xx branch of the mpc83xx repo. I had asked WD to pull into his 'testing' tree, not his master. I don't intend on getting WD to pull 837x support before he releases 1.3.0.
I have 2-3 patches (depending on how things go in linuxland) in my queue for 1.3.0, I'll make a pull request later today after I do some more testing.
Kim
In message 20071119112502.54c20905.kim.phillips@freescale.com you wrote:
I'm maintaining mpc837x support in the mpc83xx branch of the mpc83xx repo. I had asked WD to pull into his 'testing' tree, not his master. I don't intend on getting WD to pull 837x support before he releases 1.3.0.
I will usually not pull anything new into -testing or ionto any other official repo when there is no merge window open.
I have 2-3 patches (depending on how things go in linuxland) in my queue for 1.3.0, I'll make a pull request later today after I do some more testing.
At the moment, the agreement was that the first things to go in is Grant's patch set, after which you all will be busy to rebase your patches anyway ;-)
Best regards,
Wolfgang Denk
participants (5)
-
Grant Likely -
Kim Phillips -
Liu Dave -
Stefan Roese -
Wolfgang Denk