[U-Boot-Users] [GIT PULL] Please pull u-boot-arm
Wolfgang Please pull from git://www.denx.de/git/u-boot-arm.git master.
These are the patches:
[PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and cleanup [PATCH] DM644x: This patch removes all boardspecific code from the arch part for DM644x (DaVinci) boards [PATCH] DM644x: (2nd try) This adds support fortheProdrivePMDRA board, based on a DM6441 [PATCH 0/7] Respin of Sascha Hauer's i.MX31support plus MX31ADS
AFAIK there are no outstanding patches for git://www.denx.de/git/u-boot-arm.git for this merge window.
I have dropped [PATCH] ixp: Support for NSLU2 [PATCH] Altera Stratix II support as per previous mails
Regards
Peter
--- The following changes since commit 74d1e66d22dac91388bc538b2fe19f735edc5b82: Bartlomiej Sieka (1): Fix host tool build breakage, take two
are available in the git repository at:
git://www.denx.de/git/u-boot-arm.git master
Dirk Behme (1): - Remove *_masked() functions as noted by Wolfgang
Guennadi Liakhovetski (1): Support for the MX31ADS evaluation board from Freescale
Peter Pearse (2): Add pmdra into MAKEALL Bracket READ_TIMER macro in cpu/arm1136/omap24xx/interrupts.c
Pieter Voorthuijsen (2): Removes all board specific code from the arch. part for DM644x (DaVinci) boards Adds support for the Prodrive PMDRA board, based on a DM6441
Sascha Hauer (6): Separate omap24xx specific code from arm1136 core support for Freescale mx31 add an i2c driver for mx31 add SMSC LAN9x1x Network driver mx31 litekit support Phytec Phycore-i.MX31 support
MAKEALL | 4 + Makefile | 16 +- board/imx31_litekit/Makefile | 50 ++ board/imx31_litekit/config.mk | 1 + board/imx31_litekit/imx31_litekit.c | 65 ++ board/imx31_litekit/lowlevel_init.S | 103 +++ board/imx31_litekit/u-boot.lds | 59 ++ board/imx31_phycore/Makefile | 49 ++ board/imx31_phycore/config.mk | 1 + board/imx31_phycore/imx31_phycore.c | 73 +++ board/imx31_phycore/lowlevel_init.S | 105 +++ board/imx31_phycore/u-boot.lds | 59 ++ board/mx31ads/Makefile | 52 ++ board/mx31ads/config.mk | 1 + board/mx31ads/lowlevel_init.S | 288 +++++++++ board/mx31ads/mx31ads.c | 94 +++ board/mx31ads/u-boot.lds | 59 ++ board/prodrive/pmdra/Makefile | 50 ++ board/prodrive/pmdra/board_init.S | 29 + board/prodrive/pmdra/config.mk | 39 ++ board/prodrive/pmdra/pmdra.c | 189 ++++++ board/prodrive/pmdra/u-boot.lds | 52 ++ cpu/arm1136/Makefile | 2 +- cpu/arm1136/cpu.c | 11 +- cpu/arm1136/mx31/Makefile | 44 ++ cpu/arm1136/mx31/generic.c | 99 +++ cpu/arm1136/mx31/interrupts.c | 113 ++++ cpu/arm1136/mx31/serial.c | 230 +++++++ cpu/arm1136/omap24xx/Makefile | 46 ++ cpu/arm1136/{ => omap24xx}/interrupts.c | 109 ++-- cpu/arm1136/omap24xx/start.S | 42 ++ cpu/arm1136/start.S | 21 - cpu/arm926ejs/davinci/lowlevel_init.S | 79 ++- cpu/arm926ejs/davinci/nand.c | 41 +- cpu/arm926ejs/davinci/timer.c | 69 +-- drivers/i2c/Makefile | 1 + drivers/i2c/mxc_i2c.c | 207 ++++++ drivers/net/Makefile | 1 + drivers/net/smc911x.c | 680 ++++++++++++++++++++ include/asm-arm/arch-davinci/hardware.h | 2 + include/asm-arm/arch-mx31/mx31-regs.h | 151 +++++ include/asm-arm/arch-mx31/mx31.h | 32 + .../asm-arm/{arch-arm1136 => arch-omap24xx}/bits.h | 0 .../{arch-arm1136 => arch-omap24xx}/clocks.h | 0 .../asm-arm/{arch-arm1136 => arch-omap24xx}/i2c.h | 0 .../asm-arm/{arch-arm1136 => arch-omap24xx}/mem.h | 0 .../asm-arm/{arch-arm1136 => arch-omap24xx}/mux.h | 0 .../{arch-arm1136 => arch-omap24xx}/omap2420.h | 0 .../{arch-arm1136 => arch-omap24xx}/sizes.h | 0 .../{arch-arm1136 => arch-omap24xx}/sys_info.h | 0 .../{arch-arm1136 => arch-omap24xx}/sys_proto.h | 0 include/configs/davinci_dvevm.h | 44 +- include/configs/davinci_schmoogie.h | 19 +- include/configs/davinci_sonata.h | 18 + include/configs/imx31_litekit.h | 167 +++++ include/configs/imx31_phycore.h | 190 ++++++ include/configs/mx31ads.h | 170 +++++ include/configs/pmdra.h | 186 ++++++ 58 files changed, 4013 insertions(+), 199 deletions(-) create mode 100644 board/imx31_litekit/Makefile create mode 100644 board/imx31_litekit/config.mk create mode 100644 board/imx31_litekit/imx31_litekit.c create mode 100644 board/imx31_litekit/lowlevel_init.S create mode 100644 board/imx31_litekit/u-boot.lds create mode 100644 board/imx31_phycore/Makefile create mode 100644 board/imx31_phycore/config.mk create mode 100644 board/imx31_phycore/imx31_phycore.c create mode 100644 board/imx31_phycore/lowlevel_init.S create mode 100644 board/imx31_phycore/u-boot.lds create mode 100644 board/mx31ads/Makefile create mode 100644 board/mx31ads/config.mk create mode 100644 board/mx31ads/lowlevel_init.S create mode 100644 board/mx31ads/mx31ads.c create mode 100644 board/mx31ads/u-boot.lds create mode 100644 board/prodrive/pmdra/Makefile create mode 100644 board/prodrive/pmdra/board_init.S create mode 100644 board/prodrive/pmdra/config.mk create mode 100644 board/prodrive/pmdra/pmdra.c create mode 100644 board/prodrive/pmdra/u-boot.lds create mode 100644 cpu/arm1136/mx31/Makefile create mode 100644 cpu/arm1136/mx31/generic.c create mode 100644 cpu/arm1136/mx31/interrupts.c create mode 100644 cpu/arm1136/mx31/serial.c create mode 100644 cpu/arm1136/omap24xx/Makefile rename cpu/arm1136/{ => omap24xx}/interrupts.c (50%) mode change 100644 => 100755 create mode 100644 cpu/arm1136/omap24xx/start.S create mode 100644 drivers/i2c/mxc_i2c.c create mode 100644 drivers/net/smc911x.c create mode 100644 include/asm-arm/arch-mx31/mx31-regs.h create mode 100644 include/asm-arm/arch-mx31/mx31.h rename include/asm-arm/{arch-arm1136 => arch-omap24xx}/bits.h (100%) rename include/asm-arm/{arch-arm1136 => arch-omap24xx}/clocks.h (100%) rename include/asm-arm/{arch-arm1136 => arch-omap24xx}/i2c.h (100%) rename include/asm-arm/{arch-arm1136 => arch-omap24xx}/mem.h (100%) rename include/asm-arm/{arch-arm1136 => arch-omap24xx}/mux.h (100%) rename include/asm-arm/{arch-arm1136 => arch-omap24xx}/omap2420.h (100%) rename include/asm-arm/{arch-arm1136 => arch-omap24xx}/sizes.h (100%) rename include/asm-arm/{arch-arm1136 => arch-omap24xx}/sys_info.h (100%) rename include/asm-arm/{arch-arm1136 => arch-omap24xx}/sys_proto.h (100%) create mode 100644 include/configs/imx31_litekit.h create mode 100644 include/configs/imx31_phycore.h create mode 100644 include/configs/mx31ads.h create mode 100644 include/configs/pmdra.h
In message 000801c89255$d637b670$3a4d010a@Emea.Arm.com you wrote:
Wolfgang Please pull from git://www.denx.de/git/u-boot-arm.git master.
These are the patches:
[PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and cleanup [PATCH] DM644x: This patch removes all boardspecific code from the arch part for DM644x (DaVinci) boards [PATCH] DM644x: (2nd try) This adds support fortheProdrivePMDRA board, based on a DM6441 [PATCH 0/7] Respin of Sascha Hauer's i.MX31support plus MX31ADS
AFAIK there are no outstanding patches for git://www.denx.de/git/u-boot-arm.git for this merge window.
I have dropped [PATCH] ixp: Support for NSLU2 [PATCH] Altera Stratix II support as per previous mails
Applied, thanks.
Best regards,
Wolfgang Denk
I managed to get version 1.2.0 to work with my SMDK2410(ish) board and NAND flash (at least I think it works, I wrote a kernel to NAND, read it back, and booted). Considering I had barely any idea what I was doing, it was an impressive feat 8)
Now I'm wanting to take a crack at getting the smdk2410 or sbc2410 (probably the latter since it already has the extra chips configured). I'm hoping they are non-working mostly because of support file changes and just the board/include files need straightening out.
Can someone name a board that works "out of the box" with 1.3.2 that I could use for comparison with the s3c2410 boards and perhaps get it working?
It seems the s3c2410's are not well supported anywhere outside of Korea and China. (google translate has been a HUGE help even though context escapes it completely)
Dear Peter,
in message 000801c89255$d637b670$3a4d010a@Emea.Arm.com you wrote:
These are the patches:
[PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and cleanup [PATCH] DM644x: This patch removes all boardspecific code from the arch part for DM644x (DaVinci) boards [PATCH] DM644x: (2nd try) This adds support fortheProdrivePMDRA board, based on a DM6441 [PATCH 0/7] Respin of Sascha Hauer's i.MX31support plus MX31ADS
...
Guennadi Liakhovetski (1): Support for the MX31ADS evaluation board from Freescale
...
Sascha Hauer (6): Separate omap24xx specific code from arm1136 core support for Freescale mx31 add an i2c driver for mx31 add SMSC LAN9x1x Network driver mx31 litekit support Phytec Phycore-i.MX31 support
I would expect, that the state of the current repository represents what we get after applying Sascha's and Guennadi's patches (in the correct versions and order). Howver, the current tree looks totally different to me.
Can you please check with Guennadi what happened, how this can be cleaned up, and especially how this can be prevented in the future?
Note that there is not only not the expected state of the source code, but there is also corruption of meta-information again; for example:
-> git-show --pretty=fuller 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6 commit 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6 Author: Guennadi Liakhovetski <[lg@denx.de]> -------------------------------------------^^^^^^^^^^^^ AuthorDate: Sun Mar 30 11:32:30 2008 +0100 Commit: Peter Pearse peter.pearse@arm.com CommitDate: Sun Mar 30 11:32:30 2008 +0100
Support for the MX31ADS evaluation board from Freescale ...
None of Guennadis messages on the mailing list ever used something like "[lg@denx.de]" - this must be something that happend on your end when processing his patches. Where are the brackets coming from? Don't you use git-am to apply the patches?
Best regards,
Wolfgang Denk
I would expect, that the state of the current repository represents what we get after applying Sascha's and Guennadi's patches (in the correct versions and order). Howver, the current tree looks totally different to me.
There are some vital differences between the current git trees (both the ARM tree and the main tree) and the tree one gets after applying the patches manually (from the posts here on the list).
I had to make some changes in order to get the litekit to work with the git source, it seems like the phycore is also affected but I don't have such a board to test on.
The following changes to the current git will put the files into the same state as in the patches posted on the list.
At the moment I'm using gmail to post this so the diff below may be garbled, I can re-post tonight using another mailer if necessary.
Regards, Magnus Lilja
board/imx31_litekit/Makefile | 2 ++ board/imx31_litekit/lowlevel_init.S | 5 +++++ board/imx31_phycore/Makefile | 2 ++ board/imx31_phycore/lowlevel_init.S | 3 +++ 4 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/board/imx31_litekit/Makefile b/board/imx31_litekit/Makefile index aaaec69..76ed1ad 100644 --- a/board/imx31_litekit/Makefile +++ b/board/imx31_litekit/Makefile @@ -48,3 +48,5 @@ distclean: clean include $(SRCTREE)/rules.mk
sinclude $(obj).depend + +######################################################################### diff --git a/board/imx31_litekit/lowlevel_init.S b/board/imx31_litekit/lowlevel_init.S index 74d6067..c778e88 100644 --- a/board/imx31_litekit/lowlevel_init.S +++ b/board/imx31_litekit/lowlevel_init.S @@ -101,3 +101,8 @@ lowlevel_init: REG 0xB8001000, 0xb2100000 REG8 0x80000033, 0xda REG8 0x81000000, 0xff + REG 0xB8001000, 0x82226080 + REG 0x80000000, 0xDEADBEEF + REG 0xB8001010, 0x0000000c + + mov pc, lr diff --git a/board/imx31_phycore/Makefile b/board/imx31_phycore/Makefile index de37cca..f6c248d 100644 --- a/board/imx31_phycore/Makefile +++ b/board/imx31_phycore/Makefile @@ -47,3 +47,5 @@ distclean: clean include $(SRCTREE)/rules.mk
sinclude $(obj).depend + +######################################################################### diff --git a/board/imx31_phycore/lowlevel_init.S b/board/imx31_phycore/lowlevel_init.S index b0a5389..61a500e 100644 --- a/board/imx31_phycore/lowlevel_init.S +++ b/board/imx31_phycore/lowlevel_init.S @@ -103,3 +103,6 @@ lowlevel_init: REG8 0x81000000, 0xff REG 0xB8001000, 0x82226080 REG 0x80000000, 0xDEADBEEF + REG 0xB8001010, 0x0000000c + + mov pc, lr
-----Original Message----- From: Magnus Lilja [mailto:lilja.magnus@gmail.com] Sent: 10 April 2008 12:53 To: Wolfgang Denk Cc: Peter Pearse; Guennadi Liakhovetski; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
I would expect, that the state of the current repository
represents
what we get after applying Sascha's and Guennadi's patches (in the correct versions and order). Howver, the current tree looks
totally
different to me.
There are some vital differences between the current git trees (both the ARM tree and the main tree) and the tree one gets after applying the patches manually (from the posts here on the list).
Thanks Magnus
I see that in correcting the formats of the patches I have neglected to correct the line counts for new files, thus losing the final lines of the file.
Applying your patch now
Regards
Peter
On Fri, 11 Apr 2008, Peter Pearse wrote:
-----Original Message----- From: Magnus Lilja [mailto:lilja.magnus@gmail.com] Sent: 10 April 2008 12:53 To: Wolfgang Denk Cc: Peter Pearse; Guennadi Liakhovetski; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
I would expect, that the state of the current repository
represents
what we get after applying Sascha's and Guennadi's patches (in the correct versions and order). Howver, the current tree looks
totally
different to me.
There are some vital differences between the current git trees (both the ARM tree and the main tree) and the tree one gets after applying the patches manually (from the posts here on the list).
Thanks Magnus
I see that in correcting the formats of the patches I have neglected to correct the line counts for new files, thus losing the final lines of the file.
Applying your patch now
Sorry, do I understand it right, that you are going to keep your patches as you have committed them and now apply this patch from Magnus on the top? If yes, I don't think this is a correct decision. I think, you should revert your commits and re-apply the original unchanged patches.
Thanks Guennadi --- Guennadi Liakhovetski
In message Pine.LNX.4.64.0804111309060.15272@axis700.grange you wrote:
Sorry, do I understand it right, that you are going to keep your patches as you have committed them and now apply this patch from Magnus on the top? If yes, I don't think this is a correct decision. I think, you should revert your commits and re-apply the original unchanged patches.
I agree with Guennadi. The only solution is to throw away the current state of the repository, and restart from the state before all the corrupted patches were applied, adding clean, unmodified patches this time.
As for the public U-Boot repository, where such a manipulation cannot be done easily, I think I would like to revert the commits in question, i. e. this list of commits:
066bebd6353e33af3adefc3404560871699e9961 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6 c88ae20580b2b01487b4cdcc8b2a113f551aee36 a147e56f03871bba4f05058d5e04ce7deb010b04 d6674e0e2a6a1f033945f78838566210d3f28c95 8c8463cce44d849e37744749b32d38e1dfb12e50 c98b47ad24b2d91f41c09a3d62d7f70ad84f4b7d 8bf69d81782619187933a605f1a95ee1d069478d 8c16cb0d3b971f46fbe77c072664c0f2dcd4471d a574a73852a527779234e73e17e7597fd8128882 1377b5583a48021d983e1fd565f7d40c89e84d63 1704dc20917b4f71e373e2c888497ee666d40380
Comments welcome.
Best regards,
Wolfgang Denk
On Fri, 11 Apr 2008, Wolfgang Denk wrote:
In message Pine.LNX.4.64.0804111309060.15272@axis700.grange you wrote:
Sorry, do I understand it right, that you are going to keep your patches as you have committed them and now apply this patch from Magnus on the top? If yes, I don't think this is a correct decision. I think, you should revert your commits and re-apply the original unchanged patches.
I agree with Guennadi. The only solution is to throw away the current state of the repository, and restart from the state before all the corrupted patches were applied, adding clean, unmodified patches this time.
Actually, I think, even Peter should not reset his tree, but revert just as well as you are going to do it: his tree is publically accessible too, and if he resets his tree, it will become unclear, where respective commits from the central tree come from.
As for the public U-Boot repository, where such a manipulation cannot be done easily, I think I would like to revert the commits in question, i. e. this list of commits:
066bebd6353e33af3adefc3404560871699e9961 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6 c88ae20580b2b01487b4cdcc8b2a113f551aee36 a147e56f03871bba4f05058d5e04ce7deb010b04 d6674e0e2a6a1f033945f78838566210d3f28c95 8c8463cce44d849e37744749b32d38e1dfb12e50 c98b47ad24b2d91f41c09a3d62d7f70ad84f4b7d 8bf69d81782619187933a605f1a95ee1d069478d 8c16cb0d3b971f46fbe77c072664c0f2dcd4471d a574a73852a527779234e73e17e7597fd8128882 1377b5583a48021d983e1fd565f7d40c89e84d63 1704dc20917b4f71e373e2c888497ee666d40380
Comments welcome.
Right, so, I think, Peter should do the same.
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D.
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
-----Original Message----- From: Guennadi Liakhovetski [mailto:lg@denx.de] Sent: 11 April 2008 12:38 To: Wolfgang Denk Cc: Peter Pearse; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
On Fri, 11 Apr 2008, Wolfgang Denk wrote:
In message
Pine.LNX.4.64.0804111309060.15272@axis700.grange you wrote:
Sorry, do I understand it right, that you are going to keep your patches as you have committed them and now apply this patch from Magnus on the top? If yes, I don't think this is a
correct decision.
I think, you should revert your commits and re-apply the
original unchanged patches.
I agree with Guennadi. The only solution is to throw away
the current
state of the repository, and restart from the state before
all the
corrupted patches were applied, adding clean, unmodified
patches this
time.
Actually, I think, even Peter should not reset his tree, but revert just as well as you are going to do it: his tree is publically accessible too, and if he resets his tree, it will become unclear, where respective commits from the central tree come from.
Agreed.
I shall revert u-boot-arm commits in the order listed.
I understand now that I should only apply *completely* unmodified patches.
I shall investigate how I can obtain patches in an uncorrupted form and inform the patch originators when I have done so.
I may have to change my email address to do so.
Could I appeal to other u-boot guardians to send me, off list, details of which applications they have found reliable for both sending & receiving git patches.
Regards
Peter
As for the public U-Boot repository, where such a
manipulation cannot
be done easily, I think I would like to revert the commits in question, i. e. this list of commits:
066bebd6353e33af3adefc3404560871699e9961 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6 c88ae20580b2b01487b4cdcc8b2a113f551aee36 a147e56f03871bba4f05058d5e04ce7deb010b04 d6674e0e2a6a1f033945f78838566210d3f28c95 8c8463cce44d849e37744749b32d38e1dfb12e50 c98b47ad24b2d91f41c09a3d62d7f70ad84f4b7d 8bf69d81782619187933a605f1a95ee1d069478d 8c16cb0d3b971f46fbe77c072664c0f2dcd4471d a574a73852a527779234e73e17e7597fd8128882 1377b5583a48021d983e1fd565f7d40c89e84d63 1704dc20917b4f71e373e2c888497ee666d40380
Comments welcome.
Right, so, I think, Peter should do the same.
Thanks Guennadi
Guennadi Liakhovetski, Ph.D.
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
Peter Pearse wrote:
Could I appeal to other u-boot guardians to send me, off list, details of which applications they have found reliable for both sending & receiving git patches.
Can people send this info on list? I know I would like to know the answer, and I believe it would help more than just me.
Philip
On Friday 11 April 2008, Philip Balister wrote:
Peter Pearse wrote:
Could I appeal to other u-boot guardians to send me, off list, details of which applications they have found reliable for both sending & receiving git patches.
Can people send this info on list? I know I would like to know the answer, and I believe it would help more than just me.
By far the best choice for sending git generated patch is "git-send-email". As for receiving, are you sure that the received patches really are corrupted? Why does this happen? Some company mailserver problem? Perhaps this can be solved somehow. If not, then you might have to use a webmail based account for receiving.
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 Fri, 11 Apr 2008, Peter Pearse wrote:
Could I appeal to other u-boot guardians to send me, off list, details of which applications they have found reliable for both sending & receiving git patches.
Well, in many cases you can get this information from email headers, e.g.,
Message-ID: <Pine.LNX.4.64.0804111336160.15272@...>
so, just look at emails of those who seem to have no problems with patches, and, maybe, at emails of other u-boot custodians.
Thanks Guennadi --- Guennadi Liakhovetski, Ph.D.
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
Peter Pearse wrote:
[snip]
I understand now that I should only apply *completely* unmodified patches.
I shall investigate how I can obtain patches in an uncorrupted form and inform the patch originators when I have done so.
I may have to change my email address to do so.
Could I appeal to other u-boot guardians to send me, off list, details of which applications they have found reliable for both sending & receiving git patches.
Regards
Peter
[snip]
http://kerneltrap.org/Linux/Email_Clients_and_Patches
FWIIW, if your Exchange server is configured to support IMAP, you can use Thunderbird. It isn't the best client, but at least can be configured to work and doesn't spindle and mutilate received patches.
Best regards, gvb
In message 000301c89bd0$21749350$3a4d010a@Emea.Arm.com you wrote:
Actually, I think, even Peter should not reset his tree, but revert just as well as you are going to do it: his tree is publically accessible too, and if he resets his tree, it will become unclear, where respective commits from the central tree come from.
Agreed.
I shall revert u-boot-arm commits in the order listed.
OK, I reverted the commits in the master branch now.
Best regards,
Wolfgang Denk
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: 11 April 2008 14:18 To: Peter Pearse Cc: 'Guennadi Liakhovetski'; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In message 000301c89bd0$21749350$3a4d010a@Emea.Arm.com you wrote:
Actually, I think, even Peter should not reset his tree,
but revert
just as well as you are going to do it: his tree is publically accessible too, and if he resets his tree, it will become
unclear,
where respective commits from the central tree come from.
Agreed.
I shall revert u-boot-arm commits in the order listed.
OK, I reverted the commits in the master branch now.
And I've reverted u-boot-arm
Peter
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de The universe does not have laws - it has habits, and habits can be broken.
Peter Pearse wrote:
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: 11 April 2008 14:18 To: Peter Pearse Cc: 'Guennadi Liakhovetski'; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In message 000301c89bd0$21749350$3a4d010a@Emea.Arm.com you wrote:
Actually, I think, even Peter should not reset his tree,
but revert
just as well as you are going to do it: his tree is publically accessible too, and if he resets his tree, it will become
unclear,
where respective commits from the central tree come from.
Agreed.
I shall revert u-boot-arm commits in the order listed.
OK, I reverted the commits in the master branch now.
And I've reverted u-boot-arm
What's the status of re-applying the reverted patches?
I really like to see
[PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and cleanup
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38505
in mainline.
Sorry if I missed anything,
Dirk
On Friday 11 April 2008, Wolfgang Denk wrote:
In message Pine.LNX.4.64.0804111309060.15272@axis700.grange you wrote:
Sorry, do I understand it right, that you are going to keep your patches as you have committed them and now apply this patch from Magnus on the top? If yes, I don't think this is a correct decision. I think, you should revert your commits and re-apply the original unchanged patches.
I agree with Guennadi. The only solution is to throw away the current state of the repository, and restart from the state before all the corrupted patches were applied, adding clean, unmodified patches this time.
ACK. Yes, please make a fresh start.
As for the public U-Boot repository, where such a manipulation cannot be done easily, I think I would like to revert the commits in question, i. e. this list of commits:
066bebd6353e33af3adefc3404560871699e9961 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6 c88ae20580b2b01487b4cdcc8b2a113f551aee36 a147e56f03871bba4f05058d5e04ce7deb010b04 d6674e0e2a6a1f033945f78838566210d3f28c95 8c8463cce44d849e37744749b32d38e1dfb12e50 c98b47ad24b2d91f41c09a3d62d7f70ad84f4b7d 8bf69d81782619187933a605f1a95ee1d069478d 8c16cb0d3b971f46fbe77c072664c0f2dcd4471d a574a73852a527779234e73e17e7597fd8128882 1377b5583a48021d983e1fd565f7d40c89e84d63 1704dc20917b4f71e373e2c888497ee666d40380
Comments welcome.
I agree that all this should be reverted and applied again in a clean way.
Just my 2 cents.
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 =====================================================================
Dear Peter,
in message 000201c89bb3$161c3de0$3a4d010a@Emea.Arm.com you wrote:
I see that in correcting the formats of the patches I have neglected to correct the line counts for new files, thus losing the final lines of the file.
Please don't do that. Please never, never ever edit patches. It is of utmost importance that pathces that were posted on the mailing list ar applied as is, without any modifications. Please keep in mind that in most cases such patches were exported from a git repository, and applying modified patches would cause version conflicts as the original and the newly created code that are supposed to be identical are actually different.
Also, such manipulations break the whole idea of having a transparent and easily trackable development process - the original author has signed off his version of the patch, and he has a right that this patch is checked in as is (or rejected). If one applies modifications to a patch, he sneaks in his own changes completely invisible to the otherwise excellent consisitency checking of the git tools.
Peter, please stop doing this. Please make sure to apply the patches without any modifications, and please use only use git tools to do this.
If you want to make changes to the code, then please do this in a separate step, with a separate git commit which then sidentifies you as the author of these changes.
Also, please make sure not to mix changes of real content and coding style cleanup into one commit; always keep these sepoarated into independent commits - otherwise the original author of the code has serious problems to find out what was changed, and why.
I must admit that I don;t really know what to do with the current state of the git repository now. Frankly, I don't like the status quo. I think the cleanest way is to revert the changes introduced by the last pull from the u-boot-arm repository. Then you could restart the u-boot-arm from a clean state, and re-apply the list pf patches, this time unchanged. Once this has been done, I would pull again. Would such a plan be acceptable to you?
Here is the list of commits I would like to revert:
066bebd6353e33af3adefc3404560871699e9961 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6 c88ae20580b2b01487b4cdcc8b2a113f551aee36 a147e56f03871bba4f05058d5e04ce7deb010b04 d6674e0e2a6a1f033945f78838566210d3f28c95 8c8463cce44d849e37744749b32d38e1dfb12e50 c98b47ad24b2d91f41c09a3d62d7f70ad84f4b7d 8bf69d81782619187933a605f1a95ee1d069478d 8c16cb0d3b971f46fbe77c072664c0f2dcd4471d a574a73852a527779234e73e17e7597fd8128882 1377b5583a48021d983e1fd565f7d40c89e84d63 1704dc20917b4f71e373e2c888497ee666d40380
Please comment.
Best regards,
Wolfgang Denk
participants (10)
-
Dirk Behme -
Guennadi Liakhovetski -
Guennadi Liakhovetski -
Jerry Van Baren -
Magnus Lilja -
pat -
Peter Pearse -
Philip Balister -
Stefan Roese -
Wolfgang Denk