Re: [U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h
Dear Gerlando Falauto, In message 1343402200-32020-4-git-send-email-gerlando.fala...@keymile.com you wrote: Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need to keep them as separate .h config files. Therefore, make mgcoge3ne.h and mgcoge.h converge into a single km82xx.h file. Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com --- boards.cfg |4 +- include/configs/km82xx.h| 149 +++ include/configs/mgcoge.h| 93 --- include/configs/mgcoge3ne.h | 93 --- 4 files changed, 151 insertions(+), 188 deletions(-) create mode 100644 include/configs/km82xx.h delete mode 100644 include/configs/mgcoge.h delete mode 100644 include/configs/mgcoge3ne.h Applied, 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: w...@denx.de backups: always in season, never out of style. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h
Dear Wolgfang Denk, On 07/27/2012 07:30 PM, Wolfgang Denk wrote: Dear Gerlando Falauto, In message1343402200-32020-4-git-send-email-gerlando.fala...@keymile.com you wrote: Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need to keep them as separate .h config files. Therefore, make mgcoge3ne.h and mgcoge.h converge into a single km82xx.h file. Signed-off-by: Gerlando Falautogerlando.fala...@keymile.com --- boards.cfg |4 +- include/configs/km82xx.h| 149 +++ include/configs/mgcoge.h| 93 --- include/configs/mgcoge3ne.h | 93 --- 4 files changed, 151 insertions(+), 188 deletions(-) create mode 100644 include/configs/km82xx.h delete mode 100644 include/configs/mgcoge.h delete mode 100644 include/configs/mgcoge3ne.h Can you please try creating this patch with git format-patch with options -M and -C, please? I think git should do better to recognize this rename / merge of two files. I tried this but to no avail, the resulting patch is still the same. Same for patch number 4. I guess git gets confused by the fact that we are merging two files into one. What I could do is to split this commit so that, for instance, first we rename one of the files and then (on a separate commit) we move the content of one into the other. In any case, I believe git has no notion of operations like a file being embedded into another. I think the best we could do is to put such changes into a separate commit and mark it explicitly (perhaps including a sed script in the commit message) so that they can be automated in case of a rebase. Question is, is this really worth the effort? Is there a common practice for such reworks? Thank you, Gerlando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h
Dear Gerlando Falauto, In message 50164f3a.6050...@keymile.com you wrote: boards.cfg |4 +- include/configs/km82xx.h| 149 +++ include/configs/mgcoge.h| 93 --- include/configs/mgcoge3ne.h | 93 --- 4 files changed, 151 insertions(+), 188 deletions(-) create mode 100644 include/configs/km82xx.h delete mode 100644 include/configs/mgcoge.h delete mode 100644 include/configs/mgcoge3ne.h Can you please try creating this patch with git format-patch with options -M and -C, please? I think git should do better to recognize this rename / merge of two files. I tried this but to no avail, the resulting patch is still the same. Same for patch number 4. I guess git gets confused by the fact that we are merging two files into one. No, git can handle this pretty well if you tell it what you are doing. I just retested this; the result is: --- file.1| 64 --- file.2 = file.common | 64 +++ 2 files changed, 64 insertions(+), 64 deletions(-) delete mode 100644 file.1 rename file.2 = file.common (63%) What I could do is to split this commit so that, for instance, first we rename one of the files and then (on a separate commit) we move the content of one into the other. No, this can and should be done in a single commit, for example like this: 1. run: git mv include/configs/mgcoge.h include/configs/km82xx.h 2. merge include/configs/mgcoge3ne.h into include/configs/km82xx.h 3. run: git rm include/configs/mgcoge3ne.h git format-patch -M -C will then recognize what you did. Question is, is this really worth the effort? Is there a common practice for such reworks? Yes, if possible we want that git tracks such renames / merges. And here it seems easily possible. 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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h
On 07/30/2012 03:00 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message50164f3a.6050...@keymile.com you wrote:
boards.cfg |4 +-
include/configs/km82xx.h| 149
+++
include/configs/mgcoge.h| 93 ---
include/configs/mgcoge3ne.h | 93 ---
4 files changed, 151 insertions(+), 188 deletions(-)
create mode 100644 include/configs/km82xx.h
delete mode 100644 include/configs/mgcoge.h
delete mode 100644 include/configs/mgcoge3ne.h
Can you please try creating this patch with git format-patch with
options -M and -C, please? I think git should do better to
recognize this rename / merge of two files.
I tried this but to no avail, the resulting patch is still the same.
Same for patch number 4.
I guess git gets confused by the fact that we are merging two files into
one.
No, git can handle this pretty well if you tell it what you are doing.
I just retested this; the result is:
---
file.1| 64
---
file.2 = file.common | 64
+++
2 files changed, 64 insertions(+), 64 deletions(-)
delete mode 100644 file.1
rename file.2 = file.common (63%)
What I could do is to split this commit so that, for instance,
first we rename one of the files and then (on a separate commit) we move
the content of one into the other.
No, this can and should be done in a single commit, for example like this:
1. run: git mv include/configs/mgcoge.h include/configs/km82xx.h
2. merge include/configs/mgcoge3ne.h into include/configs/km82xx.h
3. run: git rm include/configs/mgcoge3ne.h
git format-patch -M -C will then recognize what you did.
The way I understand it, such renaming information is built on the fly
while building the patch (like you're suggesting, it's a parameter to
git format-patch, not to the commit itself).
In other words, a renaming is just a remove and an add (see [1]):
--
Git has a rename command git mv, but that is just for convenience. The
effect is indistinguishable from removing the file and adding another
with different name and the same content.
--
As a matter of fact, I am able to get the renaming recognized when
committing:
---
[detached HEAD 85129b8] powerpc/82xx: 1of2 move km/km82xx-common.h
within km82xx.h
1 files changed, 148 insertions(+), 0 deletions(-)
rename include/configs/{km/km82xx-common.h = km82xx.h} (71%)
---
However, I've been struggling to get this same kind of message through
git-format-patch. No way, I don't know why. I tried with -M, -M -C,
-M10%, adding [diff]\n renames = copies to ~/.gitconfig, with both
versions below, nothing. Detected as a rename at commit time, it's a
plain delete/create commit at patch creation time.
$ git --version
git version 1.7.1
$ ~/git/bin-wrappers/git --version
git version 1.7.11.3
Could you please share what GIT version you're running?
Question is, is this really worth the effort?
Is there a common practice for such reworks?
Yes, if possible we want that git tracks such renames / merges.
And here it seems easily possible.
Could you please try applying the patch to your tree (namely 3 and 4),
and then build it again by running:
git-format-patch -M30% -C
It should get detected as a rename anyway (I mean, even if applied as a
whole delete/add).
In any case, I have no clue whether git would be able to correctly (i.e.
intelligently) apply such patch to a slightly different tree (e.g.
through cherry-pick or rebase).
So for instance, in your example above, what if file.1 (whose contents
is anyway moved into file.common, regardless of rename detection) is
slightly different?
Would the patch fail? Or worse, would it silently apply by just deleting
the new file and applying the old contents (verbatim from the patch)?
I'm strongly convinced that if we want to track such changes for what
they are (code moving) so that they can be easily re-applied, we
should mark this explicitly. Even at the cost of creating multiple
patches if necessary. Since git isn't able to figure it out by itself,
the only way I can think of doing this is splitting the commit into 3 parts:
1) preparation work, adding #include statements to the old files
2) automated code moving through a script like the following (and
including it in the commit message itself)
3) cleanup changes
powerpc/82xx: 2of3 merge mgcoge.h and mgcoge3ne.h into km82xx.h
Since mgcoge and mgcoge3ne are the only km82xx boards, there is no
need to keep them as separate .h config files.
Therefore, make mgcoge3ne.h and mgcoge.h converge into a single
km82xx.h file.
Step 2 of 3: substitute include files through the following script:
INCLUDE_STMT='#include mgcoge.h'
Re: [U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h
Dear Gerlando Falauto,
In message 5016a093.6040...@keymile.com you wrote:
The way I understand it, such renaming information is built on the fly
while building the patch (like you're suggesting, it's a parameter to
git format-patch, not to the commit itself).
Yes, and I fail to understand where your problems could be.
However, I've been struggling to get this same kind of message through
git-format-patch. No way, I don't know why. I tried with -M, -M -C,
-M10%, adding [diff]\n renames = copies to ~/.gitconfig, with both
versions below, nothing. Detected as a rename at commit time, it's a
plain delete/create commit at patch creation time.
I see this (doing it all manually for testing):
- patch -p1 /tmp/patch
- git rm include/configs/mgcoge.h include/configs/mgcoge3ne.h
- git add include/configs/km82xx.h
- git commit -s -m 'test 1'
- git format-patch -M -C --stdout HEAD^ /tmp/patch
- less /tmp/patch
From 1d9ce92a542d139b78291fb4e437e538d647d55b Mon Sep 17 00:00:00 2001
From: Wolfgang Denk w...@denx.de
Date: Mon, 30 Jul 2012 17:57:53 +0200
Subject: [PATCH] test 1
Signed-off-by: Wolfgang Denk w...@denx.de
---
include/configs/{mgcoge3ne.h = km82xx.h} | 95 ++---
include/configs/mgcoge.h | 93
2 files changed, 74 insertions(+), 114 deletions(-)
rename include/configs/{mgcoge3ne.h = km82xx.h} (55%)
delete mode 100644 include/configs/mgcoge.h
...
Oops, I forgot to git add boards.cfg here, but for this test it
makes no difference.
$ git --version
git version 1.7.1
$ ~/git/bin-wrappers/git --version
git version 1.7.11.3
Could you please share what GIT version you're running?
- git --version
git version 1.7.10.4
That's what I get from the normal Fedora 17 installation.
Could you please try applying the patch to your tree (namely 3 and 4),
and then build it again by running:
git-format-patch -M30% -C
See above...
In any case, I have no clue whether git would be able to correctly (i.e.
intelligently) apply such patch to a slightly different tree (e.g.
through cherry-pick or rebase).
So for instance, in your example above, what if file.1 (whose contents
is anyway moved into file.common, regardless of rename detection) is
slightly different?
It doesn't matter. If there are conflicts, and these can be resolved,
it works just the same.
I'm strongly convinced that if we want to track such changes for what
they are (code moving) so that they can be easily re-applied, we
should mark this explicitly. Even at the cost of creating multiple
patches if necessary. Since git isn't able to figure it out by itself,
No, on contrary. This is basicly an atomic change, and we should not
artificially split it. git should have no problems with such actions,
they are really not special in any way.
the only way I can think of doing this is splitting the commit into 3 parts:
No, please don't.
Since mgcoge and mgcoge3ne are the only km82xx boards, there is no
need to keep them as separate .h config files.
Therefore, make mgcoge3ne.h and mgcoge.h converge into a single
km82xx.h file.
Step 2 of 3: substitute include files through the following script:
INCLUDE_STMT='#include mgcoge.h'
INCLUDED=include/configs/mgcoge.h
INCLUDING=include/configs/km82xx.h
Argh No, this is not what we're going to do.
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: w...@denx.de
All a hacker needs is a tight PUSHJ, a loose pair of UUOs, and a warm
place to shift.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h
On 07/30/2012 06:07 PM, Wolfgang Denk wrote:
Dear Gerlando Falauto,
In message5016a093.6040...@keymile.com you wrote:
The way I understand it, such renaming information is built on the fly
while building the patch (like you're suggesting, it's a parameter to
git format-patch, not to the commit itself).
Yes, and I fail to understand where your problems could be.
However, I've been struggling to get this same kind of message through
git-format-patch. No way, I don't know why. I tried with -M, -M -C,
-M10%, adding [diff]\n renames = copies to ~/.gitconfig, with both
versions below, nothing. Detected as a rename at commit time, it's a
plain delete/create commit at patch creation time.
I see this (doing it all manually for testing):
- patch -p1/tmp/patch
- git rm include/configs/mgcoge.h include/configs/mgcoge3ne.h
- git add include/configs/km82xx.h
- git commit -s -m 'test 1'
- git format-patch -M -C --stdout HEAD^/tmp/patch
- less /tmp/patch
From 1d9ce92a542d139b78291fb4e437e538d647d55b Mon Sep 17 00:00:00 2001
From: Wolfgang Denkw...@denx.de
Date: Mon, 30 Jul 2012 17:57:53 +0200
Subject: [PATCH] test 1
Signed-off-by: Wolfgang Denkw...@denx.de
---
include/configs/{mgcoge3ne.h = km82xx.h} | 95
++---
include/configs/mgcoge.h | 93
2 files changed, 74 insertions(+), 114 deletions(-)
rename include/configs/{mgcoge3ne.h = km82xx.h} (55%)
delete mode 100644 include/configs/mgcoge.h
...
Oops, I forgot to git add boards.cfg here, but for this test it
makes no difference.
It turns out it's a bug/limitation of git 1.7.1.
I upgraded to 1.7.10.4 and 1.7.11.3 and now I get the same results as
you do (rename detected). See new patch as a follow-up.
[...]
In any case, I have no clue whether git would be able to correctly (i.e.
intelligently) apply such patch to a slightly different tree (e.g.
through cherry-pick or rebase).
So for instance, in your example above, what if file.1 (whose contents
is anyway moved into file.common, regardless of rename detection) is
slightly different?
It doesn't matter. If there are conflicts, and these can be resolved,
it works just the same.
I'm strongly convinced that if we want to track such changes for what
they are (code moving) so that they can be easily re-applied, we
should mark this explicitly. Even at the cost of creating multiple
patches if necessary. Since git isn't able to figure it out by itself,
No, on contrary. This is basicly an atomic change, and we should not
artificially split it. git should have no problems with such actions,
they are really not special in any way.
Renaming, I understand. But merging/splitting files, I guess they should
be treated differently (i.e., as such!) IMHO, if we want repeatability
and resilience to small changes.
But git doesn't (yet?) do that, and I think it should be worked around
some other way.
the only way I can think of doing this is splitting the commit into 3 parts:
No, please don't.
Since mgcoge and mgcoge3ne are the only km82xx boards, there is no
need to keep them as separate .h config files.
Therefore, make mgcoge3ne.h and mgcoge.h converge into a single
km82xx.h file.
Step 2 of 3: substitute include files through the following script:
INCLUDE_STMT='#include mgcoge.h'
INCLUDED=include/configs/mgcoge.h
INCLUDING=include/configs/km82xx.h
Argh No, this is not what we're going to do.
Alright, your call.
Thanks for your patience.
Gerlando
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h
Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need
to keep them as separate .h config files.
Therefore, make mgcoge3ne.h and mgcoge.h converge into a single km82xx.h
file.
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
boards.cfg |4 +-
include/configs/km82xx.h| 149 +++
include/configs/mgcoge.h| 93 ---
include/configs/mgcoge3ne.h | 93 ---
4 files changed, 151 insertions(+), 188 deletions(-)
create mode 100644 include/configs/km82xx.h
delete mode 100644 include/configs/mgcoge.h
delete mode 100644 include/configs/mgcoge3ne.h
diff --git a/boards.cfg b/boards.cfg
index 2d36d83..1af87c0 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -577,8 +577,8 @@ PQ2FADS-ZU_66MHz powerpc mpc8260
mpc8260ads freesca
PQ2FADS-ZU_66MHz_lowboot powerpc mpc8260 mpc8260ads
freescale -
MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=6600,SYS_TEXT_BASE=0xFF80
PQ2FADS-ZU_lowboot powerpc mpc8260 mpc8260ads
freescale -
MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,SYS_TEXT_BASE=0xFF80
VoVPN-GW_66MHz powerpc mpc8260 vovpn-gw
funkwerk - VoVPN-GW:CLKIN_66MHz
-mgcoge powerpc mpc8260 km82xx
keymile
-mgcoge3nepowerpc mpc8260 km82xx
keymile
+mgcoge powerpc mpc8260 km82xx
keymile- km82xx:MGCOGE
+mgcoge3nepowerpc mpc8260 km82xx
keymile- km82xx:MGCOGE3NE
SCM powerpc mpc8260 -
siemens
TQM8255_AA powerpc mpc8260 tqm8260 tqc
- TQM8260:MPC8255,300MHz
TQM8260_AA powerpc mpc8260 tqm8260 tqc
- TQM8260:MPC8260,200MHz
diff --git a/include/configs/km82xx.h b/include/configs/km82xx.h
new file mode 100644
index 000..5d62f4b
--- /dev/null
+++ b/include/configs/km82xx.h
@@ -0,0 +1,149 @@
+/*
+ * (C) Copyright 2007-2011
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * High Level Configuration Options
+ * (easy to change)
+ */
+
+#define CONFIG_MPC8247
+/* MGCOGE */
+#if defined(CONFIG_MGCOGE)
+#define CONFIG_HOSTNAMEmgcoge
+#define CONFIG_KM_BOARD_EXTRA_ENV
+
+/* MGCOGE3NE */
+#elif defined(CONFIG_MGCOGE3NE)
+#define CONFIG_HOSTNAMEmgcoge3ne
+#define CONFIG_KM_82XX
+#define CONFIG_KM_BOARD_EXTRA_ENV bobcatreset=true\0
+
+#else
+#error (Board unsupported)
+#endif
+
+#defineCONFIG_SYS_TEXT_BASE0xFE00
+
+/* include common defines/options for all Keymile boards */
+#include km/keymile-common.h
+#include km/km-powerpc.h
+
+#define CONFIG_SYS_SDRAM_BASE 0x
+#define CONFIG_SYS_FLASH_BASE 0xFE00
+#define CONFIG_SYS_FLASH_SIZE 32
+#define CONFIG_SYS_FLASH_CFI
+#define CONFIG_FLASH_CFI_DRIVER
+
+/* MGCOGE */
+#if defined(CONFIG_MGCOGE)
+#define CONFIG_SYS_MAX_FLASH_BANKS 3
+/* max num of sects on one chip */
+#define CONFIG_SYS_MAX_FLASH_SECT 512
+
+#define CONFIG_SYS_FLASH_BASE_10x5000
+#define CONFIG_SYS_FLASH_SIZE_132
+#define CONFIG_SYS_FLASH_BASE_20x5200
+#define CONFIG_SYS_FLASH_SIZE_232
+
+#define CONFIG_SYS_FLASH_BANKS_LIST { CONFIG_SYS_FLASH_BASE, \
+ CONFIG_SYS_FLASH_BASE_1, \
+ CONFIG_SYS_FLASH_BASE_2 }
+#define MTDIDS_DEFAULT nor3=app
+
+/*
+ * Bank 1 - 60x bus SDRAM
+ */
+#define SDRAM_MAX_SIZE 0x0800 /* max. 128 MB */
+#define CONFIG_SYS_GLOBAL_SDRAM_LIMIT (256 20) /* less than 256 MB */
+
+/* SDRAM initialization values
+*/
+
+#define CONFIG_SYS_OR1 ((~(CONFIG_SYS_GLOBAL_SDRAM_LIMIT-1) \
+
Re: [U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h
Dear Gerlando Falauto, In message 1343402200-32020-4-git-send-email-gerlando.fala...@keymile.com you wrote: Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need to keep them as separate .h config files. Therefore, make mgcoge3ne.h and mgcoge.h converge into a single km82xx.h file. Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com --- boards.cfg |4 +- include/configs/km82xx.h| 149 +++ include/configs/mgcoge.h| 93 --- include/configs/mgcoge3ne.h | 93 --- 4 files changed, 151 insertions(+), 188 deletions(-) create mode 100644 include/configs/km82xx.h delete mode 100644 include/configs/mgcoge.h delete mode 100644 include/configs/mgcoge3ne.h Can you please try creating this patch with git format-patch with options -M and -C, please? I think git should do better to recognize this rename / merge of two files. 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: w...@denx.de Vor allem kein Gedanke! Nichts ist kompromittierender als ein Gedan- ke!- Friedrich Wilhelm Nietzsche _Der Fall Wagner_ (1888) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
