[U-Boot-Users] [PATCH] make MAKEALL more immune to merge conflicts
..by placing board entries one per line, as suggested by jdl.
Signed-off-by: Kim Phillips kim.phillips@freescale.com --- MAKEALL | 583 +++++++++++++++++++++++++++++++++++++++++++++++---------------- 1 files changed, 436 insertions(+), 147 deletions(-)
diff --git a/MAKEALL b/MAKEALL index 8c241f6..b69b6bf 100755 --- a/MAKEALL +++ b/MAKEALL @@ -26,124 +26,281 @@ LIST="" ## MPC5xx Systems #########################################################################
-LIST_5xx=" \ - cmi_mpc5xx \ +LIST_5xx=" \ + cmi_mpc5xx \ "
######################################################################### ## MPC5xxx Systems #########################################################################
-LIST_5xxx=" \ - BC3450 cm1_qp1 cpci5200 EVAL5200 \ - fo300 icecube_5100 icecube_5200 lite5200b \ - mcc200 mecp5200 motionpro o2dnt \ - pf5200 PM520 TB5200 Total5100 \ - Total5200 Total5200_Rev2 TQM5200 TQM5200_B \ - TQM5200S v38b \ +LIST_5xxx=" \ + BC3450 \ + cm1_qp1 \ + cpci5200 \ + EVAL5200 \ + fo300 \ + icecube_5100 \ + icecube_5200 \ + lite5200b \ + mcc200 \ + mecp5200 \ + motionpro \ + o2dnt \ + pf5200 \ + PM520 \ + TB5200 \ + Total5100 \ + Total5200 \ + Total5200_Rev2 \ + TQM5200 \ + TQM5200_B \ + TQM5200S \ + v38b \ "
######################################################################### ## MPC512x Systems #########################################################################
-LIST_512x=" \ - ads5121 \ +LIST_512x=" \ + ads5121 \ "
######################################################################### ## MPC8xx Systems ######################################################################### -LIST_8xx=" \ - Adder87x GENIETV MBX860T R360MPI \ - AdderII GTH MHPC RBC823 \ - ADS860 hermes MPC86xADS rmu \ - AMX860 IAD210 MPC885ADS RPXClassic \ - c2mon ICU862_100MHz MVS1 RPXlite \ - CCM IP860 NETPHONE RPXlite_DW \ - cogent_mpc8xx IVML24 NETTA RRvision \ - ELPT860 IVML24_128 NETTA2 SM850 \ - EP88x IVML24_256 NETTA_ISDN spc1920 \ - ESTEEM192E IVMS8 NETVIA SPD823TS \ - ETX094 IVMS8_128 NETVIA_V2 svm_sc8xx \ - FADS823 IVMS8_256 NX823 SXNI855T \ - FADS850SAR KUP4K pcu_e TOP860 \ - FADS860T KUP4X QS823 TQM823L \ - FLAGADM LANTEC QS850 TQM823L_LCD \ - FPS850L lwmon QS860T TQM850L \ - GEN860T MBX quantum TQM855L \ - GEN860T_SC TQM860L \ - TQM885D \ - uc100 \ - v37 \ +LIST_8xx=" \ + Adder87x \ + AdderII \ + ADS860 \ + AMX860 \ + c2mon \ + CCM \ + cogent_mpc8xx \ + ELPT860 \ + EP88x \ + ESTEEM192E \ + ETX094 \ + FADS823 \ + FADS850SAR \ + FADS860T \ + FLAGADM \ + FPS850L \ + GEN860T \ + GEN860T_SC \ + GENIETV \ + GTH \ + hermes \ + IAD210 \ + ICU862_100MHz \ + IP860 \ + IVML24 \ + IVML24_128 \ + IVML24_256 \ + IVMS8 \ + IVMS8_128 \ + IVMS8_256 \ + KUP4K \ + KUP4X \ + LANTEC \ + lwmon \ + MBX \ + MBX860T \ + MHPC \ + MPC86xADS \ + MPC885ADS \ + MVS1 \ + NETPHONE \ + NETTA \ + NETTA2 \ + NETTA_ISDN \ + NETVIA \ + NETVIA_V2 \ + NX823 \ + pcu_e \ + QS823 \ + QS850 \ + QS860T \ + quantum \ + R360MPI \ + RBC823 \ + rmu \ + RPXClassic \ + RPXlite \ + RPXlite_DW \ + RRvision \ + SM850 \ + spc1920 \ + SPD823TS \ + svm_sc8xx \ + SXNI855T \ + TOP860 \ + TQM823L \ + TQM823L_LCD \ + TQM850L \ + TQM855L \ + TQM860L \ + TQM885D \ + uc100 \ + v37 \ "
######################################################################### ## PPC4xx Systems #########################################################################
-LIST_4xx=" \ - acadia acadia_nand ADCIOP alpr \ - AP1000 AR405 ASH405 bamboo \ - bamboo_nand bubinga CANBT CMS700 \ - CPCI2DP CPCI405 CPCI4052 CPCI405AB \ - CPCI405DT CPCI440 CPCIISER4 CRAYL1 \ - csb272 csb472 DASA_SIM DP405 \ - DU405 ebony ERIC EXBITGEN \ - G2000 HH405 HUB405 JSE \ - KAREF katmai luan lwmon5 \ - METROBOX MIP405 MIP405T ML2 \ - ml300 ocotea OCRTC ORSG \ - p3p440 PCI405 pcs440ep PIP405 \ - PLU405 PMC405 PPChameleonEVB sbc405 \ - sc3 sequoia sequoia_nand taishan \ - VOH405 VOM405 W7OLMC W7OLMG \ - walnut WUH405 XPEDITE1K yellowstone \ - yosemite yucca \ +LIST_4xx=" \ + acadia \ + acadia_nand \ + ADCIOP \ + alpr \ + AP1000 \ + AR405 \ + ASH405 \ + bamboo \ + bamboo_nand \ + bubinga \ + CANBT \ + CMS700 \ + CPCI2DP \ + CPCI405 \ + CPCI4052 \ + CPCI405AB \ + CPCI405DT \ + CPCI440 \ + CPCIISER4 \ + CRAYL1 \ + csb272 \ + csb472 \ + DASA_SIM \ + DP405 \ + DU405 \ + ebony \ + ERIC \ + EXBITGEN \ + G2000 \ + HH405 \ + HUB405 \ + JSE \ + KAREF \ + katmai \ + luan \ + lwmon5 \ + METROBOX \ + MIP405 \ + MIP405T \ + ML2 \ + ml300 \ + ocotea \ + OCRTC \ + ORSG \ + p3p440 \ + PCI405 \ + pcs440ep \ + PIP405 \ + PLU405 \ + PMC405 \ + PPChameleonEVB \ + sbc405 \ + sc3 \ + sequoia \ + sequoia_nand \ + taishan \ + VOH405 \ + VOM405 \ + W7OLMC \ + W7OLMG \ + walnut \ + WUH405 \ + XPEDITE1K \ + yellowstone \ + yosemite \ + yucca \ "
######################################################################### ## MPC8220 Systems #########################################################################
-LIST_8220=" \ - Alaska8220 Yukon8220 \ +LIST_8220=" \ + Alaska8220 \ + Yukon8220 \ "
######################################################################### ## MPC824x Systems #########################################################################
-LIST_824x=" \ - A3000 barco BMW CPC45 \ - CU824 debris eXalion HIDDEN_DRAGON \ - MOUSSE MUSENKI MVBLUE \ - OXC PN62 Sandpoint8240 Sandpoint8245 \ - sbc8240 SL8245 utx8245 \ +LIST_824x=" \ + A3000 \ + barco \ + BMW \ + CPC45 \ + CU824 \ + debris \ + eXalion \ + HIDDEN_DRAGON \ + MOUSSE \ + MUSENKI \ + MVBLUE \ + OXC \ + PN62 \ + Sandpoint8240 \ + Sandpoint8245 \ + sbc8240 \ + SL8245 \ + utx8245 \ "
######################################################################### ## MPC8260 Systems (includes 8250, 8255 etc.) #########################################################################
-LIST_8260=" \ - atc cogent_mpc8260 CPU86 CPU87 \ - ep8248 ep8260 ep82xxm gw8260 \ - hymod IPHASE4539 ISPAN MPC8260ADS \ - MPC8266ADS MPC8272ADS PM826 PM828 \ - ppmc8260 Rattler8248 RPXsuper rsdproto \ - sacsng sbc8260 SCM TQM8260_AC \ - TQM8260_AD TQM8260_AE ZPC1900 \ +LIST_8260=" \ + atc \ + cogent_mpc8260 \ + CPU86 \ + CPU87 \ + ep8248 \ + ep8260 \ + ep82xxm \ + gw8260 \ + hymod \ + IPHASE4539 \ + ISPAN \ + MPC8260ADS \ + MPC8266ADS \ + MPC8272ADS \ + PM826 \ + PM828 \ + ppmc8260 \ + Rattler8248 \ + RPXsuper \ + rsdproto \ + sacsng \ + sbc8260 \ + SCM \ + TQM8260_AC \ + TQM8260_AD \ + TQM8260_AE \ + ZPC1900 \ "
######################################################################### ## MPC83xx Systems (includes 8349, etc.) #########################################################################
-LIST_83xx=" \ - MPC8313ERDB_33 MPC8313ERDB_66 MPC832XEMDS MPC8349EMDS \ - MPC8349ITX MPC8349ITXGP MPC8360EMDS sbc8349 \ - TQM834x \ +LIST_83xx=" \ + MPC8313ERDB_33 \ + MPC8313ERDB_66 \ + MPC832XEMDS \ + MPC8349EMDS \ + MPC8349ITX \ + MPC8349ITXGP \ + MPC8360EMDS \ + sbc8349 \ + TQM834x \ "
@@ -151,123 +308,223 @@ LIST_83xx=" \ ## MPC85xx Systems (includes 8540, 8560 etc.) #########################################################################
-LIST_85xx=" \ - MPC8540ADS MPC8540EVAL MPC8541CDS MPC8544DS \ - MPC8548CDS MPC8555CDS MPC8560ADS MPC8568MDS \ - PM854 PM856 sbc8540 sbc8560 \ - stxgp3 stxssa TQM8540 TQM8541 \ - TQM8555 TQM8560 \ +LIST_85xx=" \ + MPC8540ADS \ + MPC8540EVAL \ + MPC8541CDS \ + MPC8544DS \ + MPC8548CDS \ + MPC8555CDS \ + MPC8560ADS \ + MPC8568MDS \ + PM854 \ + PM856 \ + sbc8540 \ + sbc8560 \ + stxgp3 \ + stxssa \ + TQM8540 \ + TQM8541 \ + TQM8555 \ + TQM8560 \ "
######################################################################### ## MPC86xx Systems #########################################################################
-LIST_86xx=" \ - MPC8641HPCN \ +LIST_86xx=" \ + MPC8641HPCN \ "
######################################################################### ## 74xx/7xx Systems #########################################################################
-LIST_74xx=" \ - DB64360 DB64460 EVB64260 P3G4 \ - p3m7448 PCIPPC2 PCIPPC6 ZUMA \ - mpc7448hpc2 +LIST_74xx=" \ + DB64360 \ + DB64460 \ + EVB64260 \ + mpc7448hpc2 \ + P3G4 \ + p3m7448 \ + PCIPPC2 \ + PCIPPC6 \ + ZUMA \ "
-LIST_7xx=" \ - BAB7xx CPCI750 ELPPC p3m750 \ - ppmc7xx \ +LIST_7xx=" \ + BAB7xx \ + CPCI750 \ + ELPPC \ + p3m750 \ + ppmc7xx \ "
-LIST_ppc="${LIST_5xx} ${LIST_5xxx} \ - ${LIST_8xx} \ - ${LIST_8220} ${LIST_824x} ${LIST_8260} \ - ${LIST_83xx} \ - ${LIST_85xx} \ - ${LIST_86xx} \ - ${LIST_4xx} \ - ${LIST_74xx} ${LIST_7xx}" +LIST_ppc=" \ + ${LIST_5xx} \ + ${LIST_5xxx} \ + ${LIST_8xx} \ + ${LIST_8220} \ + ${LIST_824x} \ + ${LIST_8260} \ + ${LIST_83xx} \ + ${LIST_85xx} \ + ${LIST_86xx} \ + ${LIST_4xx} \ + ${LIST_74xx} \ + ${LIST_7xx} \ +"
######################################################################### ## StrongARM Systems #########################################################################
-LIST_SA="assabet dnp1110 gcplus lart shannon" +LIST_SA=" \ + assabet \ + dnp1110 \ + gcplus \ + lart \ + shannon \ +"
######################################################################### ## ARM7 Systems #########################################################################
-LIST_ARM7=" \ - armadillo B2 ep7312 evb4510 \ - impa7 integratorap ap7 ap720t \ - lpc2292sodimm modnet50 SMN42 \ +LIST_ARM7=" \ + ap7 \ + ap720t \ + armadillo \ + B2 \ + ep7312 \ + evb4510 \ + impa7 \ + integratorap \ + lpc2292sodimm \ + modnet50 \ + SMN42 \ "
######################################################################### ## ARM9 Systems #########################################################################
-LIST_ARM9=" \ - at91rm9200dk cmc_pu2 \ - ap920t ap922_XA10 ap926ejs ap946es \ - ap966 cp920t cp922_XA10 cp926ejs \ - cp946es cp966 lpd7a400 mp2usb \ - mx1ads mx1fs2 netstar omap1510inn \ - omap1610h2 omap1610inn omap730p2 sbc2410x \ - scb9328 smdk2400 smdk2410 trab \ - VCMA9 versatile versatileab versatilepb \ - voiceblue \ +LIST_ARM9=" \ + at91rm9200dk \ + cmc_pu2 \ + ap920t \ + ap922_XA10 \ + ap926ejs \ + ap946es \ + ap966 \ + cp920t \ + cp922_XA10 \ + cp926ejs \ + cp946es \ + cp966 \ + lpd7a400 \ + mp2usb \ + mx1ads \ + mx1fs2 \ + netstar \ + omap1510inn \ + omap1610h2 \ + omap1610inn \ + omap730p2 \ + sbc2410x \ + scb9328 \ + smdk2400 \ + smdk2410 \ + trab \ + VCMA9 \ + versatile \ + versatileab \ + versatilepb \ + voiceblue \ "
######################################################################### ## ARM10 Systems ######################################################################### -LIST_ARM10=" \ - integratorcp cp1026 \ +LIST_ARM10=" \ + integratorcp \ + cp1026 \ "
######################################################################### ## ARM11 Systems ######################################################################### -LIST_ARM11=" \ - cp1136 omap2420h4 \ +LIST_ARM11=" \ + cp1136 \ + omap2420h4 \ "
######################################################################### ## Xscale Systems #########################################################################
-LIST_pxa=" \ - adsvix cerf250 cradle csb226 \ - delta innokom lubbock pleb2 \ - pxa255_idp wepep250 xaeniax xm250 \ - xsengine zylonite \ +LIST_pxa=" \ + adsvix \ + cerf250 \ + cradle \ + csb226 \ + delta \ + innokom \ + lubbock \ + pleb2 \ + pxa255_idp \ + wepep250 \ + xaeniax \ + xm250 \ + xsengine \ + zylonite \ "
-LIST_ixp="ixdp425 ixdpg425 pdnb3 scpu" +LIST_ixp=" \ + ixdp425 \ + ixdpg425 \ + pdnb3 \ + scpu \ +"
-LIST_arm=" \ - ${LIST_SA} \ - ${LIST_ARM7} ${LIST_ARM9} ${LIST_ARM10} ${LIST_ARM11} \ - ${LIST_pxa} ${LIST_ixp} \ +LIST_arm=" \ + ${LIST_SA} \ + ${LIST_ARM7} \ + ${LIST_ARM9} \ + ${LIST_ARM10} \ + ${LIST_ARM11} \ + ${LIST_pxa} \ + ${LIST_ixp} \ "
######################################################################### ## MIPS Systems (default = big endian) #########################################################################
-LIST_mips4kc="incaip" +LIST_mips4kc=" \ + incaip \ +"
-LIST_mips5kc="purple" +LIST_mips5kc=" \ + purple \ +"
-LIST_au1xx0="dbau1000 dbau1100 dbau1500 dbau1550 dbau1550_el gth2" +LIST_au1xx0=" \ + dbau1000 \ + dbau1100 \ + dbau1500 \ + dbau1550 \ + dbau1550_el \ + gth2 \ +"
-LIST_mips="${LIST_mips4kc} ${LIST_mips5kc} ${LIST_au1xx0}" +LIST_mips=" \ + ${LIST_mips4kc} \ + ${LIST_mips5kc} \ + ${LIST_au1xx0} \ +"
######################################################################### ## MIPS Systems (little endian) @@ -277,36 +534,55 @@ LIST_mips4kc_el=""
LIST_mips5kc_el=""
-LIST_au1xx0_el="dbau1550_el" +LIST_au1xx0_el=" \ + dbau1550_el \ +"
-LIST_mips_el="${LIST_mips4kc_el} ${LIST_mips5kc_el} ${LIST_au1xx0_el}" +LIST_mips_el=" \ + ${LIST_mips4kc_el} \ + ${LIST_mips5kc_el} \ + ${LIST_au1xx0_el} \ +"
######################################################################### ## i386 Systems #########################################################################
-LIST_I486="sc520_cdp sc520_spunk sc520_spunk_rel" +LIST_I486=" \ + sc520_cdp \ + sc520_spunk \ + sc520_spunk_rel \ +"
-LIST_x86="${LIST_I486}" +LIST_x86=" \ + ${LIST_I486} \ +"
######################################################################### ## NIOS Systems #########################################################################
-LIST_nios=" \ - ADNPESC1 ADNPESC1_base_32 \ - ADNPESC1_DNPEVA2_base_32 \ - DK1C20 DK1C20_standard_32 \ - DK1S10 DK1S10_standard_32 DK1S10_mtx_ldk_20 \ +LIST_nios=" \ + ADNPESC1 \ + ADNPESC1_base_32 \ + ADNPESC1_DNPEVA2_base_32\ + DK1C20 \ + DK1C20_standard_32 \ + DK1S10 \ + DK1S10_standard_32 \ + DK1S10_mtx_ldk_20 \ "
######################################################################### ## Nios-II Systems #########################################################################
-LIST_nios2=" \ - EP1C20 EP1S10 EP1S40 \ - PCI5441 PK1C20 \ +LIST_nios2=" \ + EP1C20 \ + EP1S10 \ + EP1S40 \ + PCI5441 \ + PK1C20 \ "
######################################################################### @@ -314,31 +590,44 @@ LIST_nios2=" \ #########################################################################
LIST_microblaze=" \ - suzaku ml401 xupv2p + suzaku \ + ml401 \ + xupv2p \ "
######################################################################### ## ColdFire Systems #########################################################################
-LIST_coldfire=" \ - cobra5272 EB+MCF-EV123 EB+MCF-EV123_internal \ - idmr M5271EVB M5272C3 M5282EVB \ - TASREG r5200 M5271EVB \ +LIST_coldfire=" \ + cobra5272 \ + EB+MCF-EV123 \ + EB+MCF-EV123_internal \ + idmr \ + M5271EVB \ + M5272C3 \ + M5282EVB \ + TASREG \ + r5200 \ "
######################################################################### ## AVR32 Systems #########################################################################
-LIST_avr32="atstk1002" +LIST_avr32=" \ + atstk1002 \ +"
######################################################################### ## Blackfin Systems #########################################################################
-LIST_blackfin=" \ - bf533-ezkit bf533-stamp bf537-stamp bf561-ezkit \ +LIST_blackfin=" \ + bf533-ezkit \ + bf533-stamp \ + bf537-stamp \ + bf561-ezkit \ "
#-----------------------------------------------------------------------
Dear Kim,
in message 20070806190637.e284487e.kim.phillips@freescale.com you wrote:
..by placing board entries one per line, as suggested by jdl.
I understand the intention, but at least for me it is pretty counterproductive. I introduced the block formatting some years ago when the number of boards grew, and the file grew too long.
For example, have a look at the 8xx boards. Here is the old version:
-LIST_8xx=" \
- Adder87x GENIETV MBX860T R360MPI \
- AdderII GTH MHPC RBC823 \
- ADS860 hermes MPC86xADS rmu \
- AMX860 IAD210 MPC885ADS RPXClassic \
- c2mon ICU862_100MHz MVS1 RPXlite \
- CCM IP860 NETPHONE RPXlite_DW \
- cogent_mpc8xx IVML24 NETTA RRvision \
- ELPT860 IVML24_128 NETTA2 SM850 \
- EP88x IVML24_256 NETTA_ISDN spc1920 \
- ESTEEM192E IVMS8 NETVIA SPD823TS \
- ETX094 IVMS8_128 NETVIA_V2 svm_sc8xx \
- FADS823 IVMS8_256 NX823 SXNI855T \
- FADS850SAR KUP4K pcu_e TOP860 \
- FADS860T KUP4X QS823 TQM823L \
- FLAGADM LANTEC QS850 TQM823L_LCD \
- FPS850L lwmon QS860T TQM850L \
- GEN860T MBX quantum TQM855L \
- GEN860T_SC TQM860L \
TQM885D \uc100 \v37 \
This fits easily all on a single screen.
Now your list version is about 4 times as long, and needs more than 2 pages on the (pretty big) window size I'm using. That's much harder to read.
As for the merge conflict problem: yes, this happens occasionally, but not very frequently, and this type of merge conflicts are easy to resolve.
I would like to keep the current formatting.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Tuesday 07 August 2007, Wolfgang Denk wrote:
Now your list version is about 4 times as long, and needs more than 2 pages on the (pretty big) window size I'm using. That's much harder to read.
As for the merge conflict problem: yes, this happens occasionally, but not very frequently, and this type of merge conflicts are easy to resolve.
I happens to me quite often and I don't see a big advantage in the overview view for all the boards on one page.
I would like to keep the current formatting.
I vote for the new, single-line version suggested by Kim & Jon.
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 =====================================================================
u-boot-users-bounces@lists.sourceforge.net wrote on :
Hi Wolfgang,
On Tuesday 07 August 2007, Wolfgang Denk wrote:
Now your list version is about 4 times as long, and needs more than 2 pages on the (pretty big) window size I'm using. That's much harder to read.
As for the merge conflict problem: yes, this happens occasionally, but not very frequently, and this type of merge conflicts are easy to resolve.
I happens to me quite often and I don't see a big advantage in the overview view for all the boards on one page.
Me too.
I would like to keep the current formatting.
I vote for the new, single-line version suggested by Kim & Jon.
Me too!
Best Regards,
Martin Krause -- TQ-Systems GmbH Muehlstrasse 2, Gut Delling, D-82229 Seefeld Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913 Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl http://www.tq-group.com
I would like to point out another thing that bothers me here: Whenever I take the most up to date version of U-Boot, I need to perform a merge on MAKEALL, as my local version includes the names of all my custom boards. I guess I'm not the only one bothered by this. I suggest that each processor family line in MAKEALL will hold an additional "external boards" variable, which will hold a list of all the external boards (for this family). The value of this variable should be achieved from an "external boards" makefile, included by MAKEALL. This file is obviously empty in the U-boot repository, and filled with one's own custom boards elsewhere. Just my two cents. David.
Martin Krause wrote:
u-boot-users-bounces@lists.sourceforge.net wrote on :
Hi Wolfgang,
On Tuesday 07 August 2007, Wolfgang Denk wrote:
Now your list version is about 4 times as long, and needs more than 2 pages on the (pretty big) window size I'm using. That's much harder to read.
As for the merge conflict problem: yes, this happens occasionally, but not very frequently, and this type of merge conflicts are easy to resolve.
I happens to me quite often and I don't see a big advantage in the overview view for all the boards on one page.
Me too.
I would like to keep the current formatting.
I vote for the new, single-line version suggested by Kim & Jon.
Me too!
Best Regards,
Martin Krause
TQ-Systems GmbH Muehlstrasse 2, Gut Delling, D-82229 Seefeld Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913 Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl http://www.tq-group.com
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 12052243.post@talk.nabble.com you wrote:
I would like to point out another thing that bothers me here: Whenever I take the most up to date version of U-Boot, I need to perform a merge on MAKEALL, as my local version includes the names of all my custom boards. I guess I'm not the only one bothered by this. I suggest that each processor family line in MAKEALL will hold an additional "external boards" variable, which will hold a list of all the external boards (for this family). The value of this variable should be achieved from an "external boards" makefile, included by MAKEALL. This file is obviously empty in the U-boot repository, and filled with one's own custom boards elsewhere.
What is an "external board"? I don;t understand the concept.
May I instead recommend that you submit your stuff for inclusion in the public tree?
Best regards,
Wolfgang Denk
On Wed, 2007-08-08 at 10:43, Wolfgang Denk wrote:
In message 12052243.post@talk.nabble.com you wrote:
I would like to point out another thing that bothers me here: Whenever I take the most up to date version of U-Boot, I need to perform a merge on MAKEALL, as my local version includes the names of all my custom boards. I guess I'm not the only one bothered by this. I suggest that each processor family line in MAKEALL will hold an additional "external boards" variable, which will hold a list of all the external boards (for this family). The value of this variable should be achieved from an "external boards" makefile, included by MAKEALL. This file is obviously empty in the U-boot repository, and filled with one's own custom boards elsewhere.
What is an "external board"? I don;t understand the concept.
I think he means more like "extra boards".
May I instead recommend that you submit your stuff for inclusion in the public tree?
Exactly those "extra" boards that have not been sent upstream yet. :-)
jdl
In message 1186588768.3283.4.camel@ld0161-tx32 you wrote:
I think he means more like "extra boards".
May I instead recommend that you submit your stuff for inclusion in the public tree?
Exactly those "extra" boards that have not been sent upstream yet. :-)
Well, in that case we should help David to send these upstream, i. e. *not* add anything which makes living with "extra boards" easier.
Best regards,
Wolfgang Denk
I think he means more like "extra boards".
Yes, that was indeed my intention...
May I instead recommend that you submit your stuff for inclusion in the public tree?
Exactly those "extra" boards that have not been sent upstream yet. :-)
I guess I should have been clearer, but John understood my exact take on this: Our boards will only become operational in about a year. There's no point in sending them upstream until then (we don't even have prototypes...). Furthermore, Wolfgang may disagree here, but I really think that only reference boards (i.e. boards needed for evaluation of processors etc.) should be merged into U-boot's main stream repository. Our boards are just variations of the Freescale reference boards, and I guess that's the same for many other boards by other companies. I wouldn't want to see ALL these boards merged into U-boot. Of course that if one finds a problem, or have an improvement, one's expected to send a patch to the proper place (as I did with the 83xx Makefile). Needless to say that the boards' code should be published due to GPL terms, but again - don't think it should be in the main U-boot repository. If you agree with me, then my suggestion would spare you the pain of merging the names of your boards (again - the ones that are either not ready for upstream merging, or the ones that are not supposed to go to U-boot's repos) into MAKEALL. Best regards, David.
On 8/9/07, David Saada David.Saada@ecitele.com wrote:
Furthermore, Wolfgang may disagree here, but I really think that only reference boards (i.e. boards needed for evaluation of processors etc.) should be merged into U-boot's main stream repository. Our boards are just variations of the Freescale reference boards, and I guess that's the same for many other boards by other companies. I wouldn't want to see ALL these boards merged into U-boot. Of course that if one finds a problem, or have an improvement, one's expected to send a patch to the proper place (as I did with the 83xx Makefile). Needless to say that the boards' code should be published due to GPL terms, but again - don't think it should be in the main U-boot repository.
I disagree. :-) I think you're opinions makes the assumption that u-boot is a product. It is not; it is a process. What I mean here is that our primary goal is to continually develop the best bootloader. The exact set of boards that compiles out of the box is a secondary objective. Your argument is that if it's not a generally available board, then it is uninteresting. That viewpoint makes sense if you view u-boot as a thing that you take, modify and ship (ie. a product which you consume).
However, the u-boot project is about the *process* of developing the end product. It involves understanding how u-boot is being used in real-world scenarios. It involves recognizing patterns in the code and consolidating on common patterns. We *NEED* real world board ports to have a better understanding of how to improve u-boot. My view is exactly the opposite; obscure boards are not uninteresting, they are extremely interesting.
If you agree with me, then my suggestion would spare you the pain of merging the names of your boards (again - the ones that are either not ready for upstream merging, or the ones that are not supposed to go to U-boot's repos) into MAKEALL. Best regards, David.
-- View this message in context: http://www.nabble.com/-PATCH--make-MAKEALL-more-immune-to-merge-conflicts-tf... Sent from the Uboot - Users mailing list archive at Nabble.com.
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Dear David,
in message 12068826.post@talk.nabble.com you wrote:
Furthermore, Wolfgang may disagree here, but I really think that only reference boards (i.e. boards needed for evaluation of processors etc.) should be merged into U-boot's main stream repository. Our boards are just variations of the Freescale reference boards, and I guess that's the same for many other boards by other companies. I wouldn't want to see ALL these boards merged into U-boot. Of course that if one finds a problem, or have an
Grant already replied on this, and I just want to point out that I absolutely agree with him. Just taking a huge amount of code that's publicly available for free, adding your own little stuff and never returning it to the community is something what happens here and there, but it is definitely NOT the way the free software community works, and in my opinion also pretty unethical.
Even if your board is just a minor variation of some reference board it is nevertheless important to have your changes and additions merged back into the public U-Boot source code. Guess how support for all that many types of flash chips, RTCs, PHYs, network controllers, ... you nameit ... got into the U-Boot tree? Not because these were used on reference boards, but on the plethora of different custom boards we support.
Guess where allt eh fancy features are coming from - support for graphical console, splash screen, net console, VLAN, POST code, ... came from? None of this was done for any reference board, it was all done for custom boards.
U-Boot would never even be half of what it is today if we added only reference boards.
Best regards,
Wolfgang Denk
On Aug 8, 2007, at 11:43 AM, Wolfgang Denk wrote:
What is an "external board"? I don;t understand the concept.
I think David is suggesting that we divide MAKEALL into multiple files, one per processor family or something like that. For instance, all Freescale boards could have their own MAKEALL file, so that if someone creates a new ARM board, there is no way there would be a merge conflict.
Either way, I am also voting for the one-board-per-line change. I hate merge conflicts, even easy ones, so I'm in favor of any change that reduces them.
Hi,
I happens to me quite often and I don't see a big advantage in the overview view for all the boards on one page.
I would like to keep the current formatting.
I vote for the new, single-line version suggested by Kim & Jon.
I *think* my precursors already got Wolfgang to change the format, but just for the records - I would also like to switch to a single line version.
Cheers Detlev
In message m2sl6u0y37.fsf@ohwell.denx.de you wrote:
I *think* my precursors already got Wolfgang to change the format, but just for the records - I would also like to switch to a single line version.
D*mn. Seems I'm on the side of snake eyes tossed against the side of seven again :-(
But then we should do things Right (tm):
Then please get rid of the same lists in the README as well.
Best regards,
Wolfgang Denk
On Wed, 08 Aug 2007 20:09:21 +0200 Wolfgang Denk wd@denx.de wrote:
But then we should do things Right (tm):
Then please get rid of the same lists in the README as well.
you mean delete the outdated CPU Type, Board Type, and NAME_config lists?
Kim
In message 20070810025436.0d294d8d.kim.phillips@freescale.com you wrote:
Then please get rid of the same lists in the README as well.
you mean delete the outdated CPU Type, Board Type, and NAME_config lists?
Yepp...
Best regards,
Wolfgang Denk
On Tue, 07 Aug 2007 08:48:48 +0200 Wolfgang Denk wd@denx.de wrote:
- FPS850L lwmon QS860T TQM850L \
- GEN860T MBX quantum TQM855L \
- GEN860T_SC TQM860L \
TQM885D \uc100 \v37 \This fits easily all on a single screen.
I can't imagine the level of pain one would have to (unnecessarily) endure resolving a conflict in the 8xx list (the columns don't even have equal lengths).
Now your list version is about 4 times as long, and needs more than 2 pages on the (pretty big) window size I'm using. That's much harder to read.
true, but at least it's sorted alpha now.
As for the merge conflict problem: yes, this happens occasionally, but not very frequently, and this type of merge conflicts are easy to resolve.
I'd rather say adieu to them period, given the number of trees one has to merge to get what u-boot code they want these days.
I would like to keep the current formatting.
I think you're placing too much emphasis over your /static/ aesthetics over the aesthetics of /change/, e.g. here's a patch I'm about to send you (assuming you apply this patch):
From 40f9d74666e8f521ae1d64f5b34792f7c03d883b Mon Sep 17 00:00:00 2001
From: Kim Phillips kim.phillips@freescale.com Date: Mon, 6 Aug 2007 18:46:13 -0500 Subject: [PATCH] mpc83xx: add the mpc8323erdb to MAKEALL
Signed-off-by: Kim Phillips kim.phillips@freescale.com --- MAKEALL | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/MAKEALL b/MAKEALL index b69b6bf..def4f65 100755 --- a/MAKEALL +++ b/MAKEALL @@ -294,6 +294,7 @@ LIST_8260=" \ LIST_83xx=" \ MPC8313ERDB_33 \ MPC8313ERDB_66 \ + MPC8323ERDB \ MPC832XEMDS \ MPC8349EMDS \ MPC8349ITX \
participants (9)
-
David Saada -
Detlev Zundel -
Grant Likely -
Jon Loeliger -
Kim Phillips -
Martin Krause -
Stefan Roese -
Timur Tabi -
Wolfgang Denk