Adding support for DevKit8000
PATCH v3 1/1 Adding support for DevKit8000
This patch adds support for the DevKit8000 board.
---mach-types.h needs to be synced (MACH_TYPE_DEVKIT8000)
--- MAINTAINERS | 4 + MAKEALL | 1 + Makefile | 3 + board/devkit8000/Makefile | 52 ++++++ board/devkit8000/config.mk | 35 ++++ board/devkit8000/devkit8000.c | 127 ++++++++++++++ board/devkit8000/devkit8000.h | 373 +++++++++++++++++++++++++++++++++++++++++ doc/README.devkit8000 | 8 + include/configs/devkit8000.h | 322 +++++++++++++++++++++++++++++++++++ 9 files changed, 925 insertions(+), 0 deletions(-) create mode 100644 board/devkit8000/Makefile create mode 100644 board/devkit8000/config.mk create mode 100644 board/devkit8000/devkit8000.c create mode 100644 board/devkit8000/devkit8000.h create mode 100644 doc/README.devkit8000 create mode 100644 include/configs/devkit8000.h
MAINTAINERS +4 -0
@@ -706,6 +706,10 @@ Alex Z lart SA1100 dnp1110 SA1110 +Frederik Kriewitz <[email protected]> + + devkit8000 ARM CORTEX-A8 (OMAP3530 SoC) + ------------------------------------------------------------------------- Unknown / orphaned boards:
MAKEALL +1 -0
@@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8=" \ omap3_pandora \ omap3_zoom1 \ omap3_zoom2 \ + devkit8000 \ " #########################################################################
Makefile +3 -0
@@ -3066,6 +3066,9 @@ SMN42_config : unconfig ## ARM CORTEX Systems ######################################################################### +devkit8000_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 devkit8000 NULL omap3 + omap3_beagle_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 beagle omap3 omap3
board/devkit8000/Makefile new file +52 -0
52 lines not on this page · raw message
board/devkit8000/config.mk new file +35 -0
@@ -0,0 +1,35 @@ +# +# (C) Copyright 2006 +# Texas Instruments, <www.ti.com> +# +# (C) Copyright 2009 +# Frederik Kriewitz <[email protected]> +# +# DevKit8000 uses OMAP3 (ARM-CortexA8) cpu +# see http://www.ti.com/ for more information on Texas Instruments +# +# 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 +# +# Physical Address: +# 8000'0000 (bank0) +# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 +# (mem base + reserved) + +# For use with external or internal boots. +TEXT_BASE = 0x80e80000
board/devkit8000/devkit8000.c new file +127 -0
127 lines not on this page · raw message
board/devkit8000/devkit8000.h new file +373 -0
373 lines not on this page · raw message
doc/README.devkit8000 new file +8 -0
@@ -0,0 +1,8 @@ +The OMAP3 DevKit8000 from Embest/Timll is a clone of the OMAP3 beagle board +with Ethernet and Touch Screen on board. + +For more information go to: +http://www.embedinfo.com/English/Product/devkit8000.asp + +There's no real MAC address available. +If ethaddr is not set, 5 Bytes of the OMAP Die ID will be used.
include/configs/devkit8000.h new file +322 -0
322 lines not on this page · raw message
Signature · 1 line
1.6.3.3
PATCH v3 1/1 Adding support for DevKit8000
Hi Frederik,
I had some minor aesthetic nitpicks. I'd change the title to "Add support for the DevKit8000 board".
<snip>
MAINTAINERS Alex Z · line 712
Quoted 12 lines
MAINTAINERS +4
-0@@ -706,6 +706,10 @@ Alex Z lart SA1100 dnp1110 SA1110 +Frederik Kriewitz <[email protected]> + + devkit8000 ARM CORTEX-A8 (OMAP3530 SoC) +
You should maintain the alphabetical order of MAINTAINERS when adding yourself.
MAKEALL LIST_ARM_CORTEX_A8=" \ · line 585
Quoted 13 lines
MAINTAINERS +0
-0------------------------------------------------------------------------- Unknown / orphaned boards:MAKEALL +1
-0@@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8=" \ omap3_pandora \ omap3_zoom1 \ omap3_zoom2 \ + devkit8000 \ "
You should maintain the alphabetical order of LIST_ARM_CORTEX_A8.
<snip>
MAKEALL LIST_ARM_CORTEX_A8=" \
Quoted 5 lines
MAKEALL +5
-0+/*----------------------------------------------------------------------- + * Stack sizes + * + * The stack sizes are set up in start.S using the settings below + */
Other's might disagree, but I think the "----" in the comments above are not necessary/non-standard. I'd personally use:
/*
* Stack sizes
*
* The stack sizes are set up in start.S using the settings below */
Or just:
/* The stack sizes are set up in start.S using the settings below */
Quoted 12 lines
MAKEALL +12
-0+#define CONFIG_STACKSIZE SZ_128K /* regular stack */ +#ifdef CONFIG_USE_IRQ +#define CONFIG_STACKSIZE_IRQ SZ_4K /* IRQ stack */ +#define CONFIG_STACKSIZE_FIQ SZ_4K /* FIQ stack */ +#endif + +/*----------------------------------------------------------------------- + * Physical Memory Map + */ +#define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be populated */ +#define PHYS_SDRAM_1 OMAP34XX_SDRC_CS0 +#define PHYS_SDRAM_1_SIZE SZ_128M /* at least 128 meg */
MAKEALL
Quoted 10 lines
MAKEALL +10
-0+#define PHYS_SDRAM_2 OMAP34XX_SDRC_CS1 + +/* SDRAM Bank Allocation method */ +#define SDRC_R_B_C 1 + +/*----------------------------------------------------------------------- + * FLASH and environment organization + */ + +/* **** PISMO SUPPORT *** */
You should use a standard comment style for "PISMO SUPPORT", eg less *'s and standard capitalization.
MAKEALL
Quoted 2 lines
MAKEALL +2
-0+ +/* Configure the PISMO */
Maybe get rid of the above comment too - its pretty clear that you're configuring the PISMO based on the "PISMO SUPPORT" comment above and the define name.
Quoted 1 line
+#define
PISMO1_NAND_SIZEGPMC_SIZE_128M
Best,
Peter
PATCH v3 1/1 Adding support for DevKit8000
Quoted 5 lines · Peter Tyser
Hi Frederik,
I had some minor aesthetic nitpicks. I'd change the title to "Add support for the DevKit8000 board".<snip>
Quoted 13 lines
MAKEALL LIST_ARM_CORTEX_A8=" \ · line 585
Quoted 11 lines
Unknown / orphaned boards:
MAKEALL +1
-0@@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8=" \ omap3_pandora \ omap3_zoom1 \ omap3_zoom2 \ + devkit8000 \ "You should maintain the alphabetical order of
LIST_ARM_CORTEX_A8.
What's about using 'omap3_devkit8000' ?
Best regards
Dirk
PATCH v3 1/1 Adding support for DevKit8000
Quoted 6 lines · Dirk Behme
Quoted 5 lines · Peter Tyser
Hi Frederik,
I had some minor aesthetic nitpicks. ?I'd change the title to "Add support for the DevKit8000 board".
I'll fix them
Quoted 16 lines
Quoted 14 lines
Quoted 11 lines
?Unknown / orphaned boards:
MAKEALL +1
-0@@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8=" ? ? ? ? ? ? ? ?\ ? ? ? ?omap3_pandora ? ? ? ? ? \ ? ? ? ?omap3_zoom1 ? ? ? ? ? ? \ ? ? ? ?omap3_zoom2 ? ? ? ? ? ? \ + ? ? ? devkit8000 ? ? ?\Quoted 1 line
?"
You should maintain the alphabetical order of
LIST_ARM_CORTEX_A8.What's about using '
omap3_devkit8000' ?
Quoted 3 lines · Peter Tyser
Hi Frederik,
I had some minor aesthetic nitpicks. I'd change the title to "Add support for the DevKit8000 board".
Ok, I'll fix them.
Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
Quoted 9 lines · Frederik Kriewitz
Quoted 6 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 4 lines
board/omap3/devkit8000/Makefile | 52 +++++ board/omap3/devkit8000/config.mk | 35 ++++ board/omap3/devkit8000/devkit8000.c | 124 ++++++++++++ board/omap3/devkit8000/devkit8000.h | 373 +++++++++++++++++++++++++++++++++++no need board are allow in board/omap3
please create your own vendor dirent or just put it in board/What do you mean with that?
board/devkit8000/devkit8000.h
or board/embedinfo/devkit8000/devkit8000.h
I'm confused, where am I supposed to use omap3 and where not?
PATCH v3 1/1 Adding support for DevKit8000
Quoted 27 lines · Frederik Kriewitz
Quoted 6 lines · Dirk Behme
Quoted 5 lines · Peter Tyser
Hi Frederik,
I had some minor aesthetic nitpicks. ?I'd change the title to "Add support for the DevKit8000 board".I'll fix them
Quoted 15 lines
Quoted 14 lines
Quoted 11 lines
?Unknown / orphaned boards:
MAKEALL +1
-0@@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8=" ? ? ? ? ? ? ? ?\ ? ? ? ?omap3_pandora ? ? ? ? ? \ ? ? ? ?omap3_zoom1 ? ? ? ? ? ? \ ? ? ? ?omap3_zoom2 ? ? ? ? ? ? \ + ? ? ? devkit8000 ? ? ?\Quoted 1 line
?"
You should maintain the alphabetical order of
LIST_ARM_CORTEX_A8.Quoted 1 line
What's about using '
omap3_devkit8000' ?
Quoted 8 lines
Quoted 3 lines · Peter Tyser
Hi Frederik,
I had some minor aesthetic nitpicks. I'd change the title to "Add support for the DevKit8000 board".Ok, I'll fix them.
Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
I agree with Dirk for the config name it will be good to have omap3_devkit8000 but if you prefer devkit8000 it's fine also
and yes I've ask you about the boardir to move it out of the omap3 dirent
Best Regards,
J.
PATCH v3 1/1 Adding support for DevKit8000
In reply to Frederik KriewitzQuoted 9 lines · Frederik Kriewitz
Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
Quoted 6 lines · Frederik Kriewitz
Quoted 4 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 4 lines
board/omap3/devkit8000/Makefile | 52 +++++ board/omap3/devkit8000/config.mk | 35 ++++ board/omap3/devkit8000/devkit8000.c | 124 ++++++++++++ board/omap3/devkit8000/devkit8000.h | 373 +++++++++++++++++++++++++++++++++++
Quoted 7 lines
Quoted 3 lines
Quoted 2 lines
no need board are allow in board/omap3
please create your own vendor dirent or just put it in board/What do you mean with that?
board/devkit8000/devkit8000.h
orboard/embedinfo/devkit8000/devkit8000.hI'm confused, where am I supposed to use omap3 and where not?
Yes, sometimes it can be confusing ;)
From earlier discussions I understood that Jean-Christophe doesn't like
board/omap3/
I'm not totally sure what he actually wants, but I think something like
board/ti/omap3
board/ti/omap2
board/ti/omap1
board/ti/davinci
etc. (e.g. like board/atmel).
While I don't care what we use, like with other discussions we should do it consistent. That is, having already x boards in omap3 and now adding the next board somewhere else isn't ok. As long as we don't have the new directory layout, new boards should use the old one. If we want an other directory layout, we should *first* move all existing boards to the other directory (ideally doing this directly in git). *Then* new patches can and have to use this new layout.
Conclusion: Until we don't have an other directory layout, I'm fine with board/omap3/devkit8000
Best regards
Dirk
PATCH v3 1/1 Adding support for DevKit8000
Hi Dirk,
Quoted 24 lines · Dirk Behme
Quoted 9 lines · Frederik Kriewitz
Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
Quoted 6 lines · Frederik Kriewitz
Quoted 4 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 4 lines
board/omap3/devkit8000/Makefile | 52 +++++ board/omap3/devkit8000/config.mk | 35 ++++ board/omap3/devkit8000/devkit8000.c | 124 ++++++++++++ board/omap3/devkit8000/devkit8000.h | 373 +++++++++++++++++++++++++++++++++++Quoted 7 lines
Quoted 3 lines
Quoted 2 lines
no need board are allow in board/omap3
please create your own vendor dirent or just put it in board/What do you mean with that?
board/devkit8000/devkit8000.h
orboard/embedinfo/devkit8000/devkit8000.hI'm confused, where am I supposed to use omap3 and where not?
Yes, sometimes it can be confusing ;)
From earlier discussions I understood that Jean-Christophe doesn't like
board/omap3/
Quoted 8 lines
I'm not totally sure what he actually wants, but I think something like
board/ti/omap3
board/ti/omap2
board/ti/omap1
board/ti/davincietc. (e.g. like board/atmel).
My understanding is that the board/ layout should be "/board/<board vendor or board name>/...". So even though the Frederik's board has a TI OMAP3 cpu, he shouldn't put it in board/ti or board/omap3 since neither TI nor OMAP3 made the DevKit8000.
I believe all the boards in board/atmel are made by atmel and use atmel cpus, same with board/freescale. But if anyone else makes a custom atmel or freescale-based board, it should not go in board/atmel or board/freescale.
For example, there are mpc8548, mpc8572, mpc8548, and amcc440-based boards in board/xes, but they are all made by the X-ES company.
Jean-Christophe is saying you should put your board in either:
board/devkit8000/
or, if your company (embedinfo?) plans on adding more than just the devkit8000, put it in:
board/embedinfo/devkit8000 board/embedinto/<future_board_x>
Quoted 7 lines
While I don't care what we use, like with other discussions we should do it consistent. That is, having already x boards in omap3 and now adding the next board somewhere else isn't ok. As long as we don't have the new directory layout, new boards should use the old one. If we want an other directory layout, we should *first* move all existing boards to the other directory (ideally doing this directly in git). *Then* new patches can and have to use this new layout.
I agree that other boards currently in board/omap3 should be moved to an appropriate board/<board vendor or board name> directory in the long run, ideally sooner rather than later:) That being said, I think it would make sense to put the devkit8000 in either board/devkit8000/ or board/embedinfo/devkit8000 now as that is the "correct" place for it.
Quoted 2 lines
Conclusion: Until we don't have an other directory layout, I'm fine with board/omap3/devkit8000
Doesn't really matter to me, just thought I'd mention my $.02 about how thing should be organized in the long run.
Best,
Peter
[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000
Quoted 39 lines · Peter Tyser
Hi Dirk,
Quoted 23 lines · Dirk Behme
Quoted 9 lines · Frederik Kriewitz
Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
Quoted 6 lines · Frederik Kriewitz
Quoted 4 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 4 lines
board/omap3/devkit8000/Makefile | 52 +++++ board/omap3/devkit8000/config.mk | 35 ++++ board/omap3/devkit8000/devkit8000.c | 124 ++++++++++++ board/omap3/devkit8000/devkit8000.h | 373 +++++++++++++++++++++++++++++++++++Quoted 7 lines
Quoted 3 lines
Quoted 2 lines
no need board are allow in board/omap3
please create your own vendor dirent or just put it in board/What do you mean with that?
board/devkit8000/devkit8000.h
orboard/embedinfo/devkit8000/devkit8000.hI'm confused, where am I supposed to use omap3 and where not?
Yes, sometimes it can be confusing ;)
From earlier discussions I understood that Jean-Christophe doesn't like
board/omap3/
Quoted 8 lines
I'm not totally sure what he actually wants, but I think something like
board/ti/omap3
board/ti/omap2
board/ti/omap1
board/ti/davincietc. (e.g. like board/atmel).
My understanding is that the board/ layout should be "/board/<board vendor or board name>/...". So even though the Frederik's board has a TI OMAP3 cpu, he shouldn't put it in board/ti or board/omap3 since neither TI nor OMAP3 made the DevKit8000.
...
Quoted 10 lines
For example, there are mpc8548, mpc8572, mpc8548, and amcc440-based boards in board/xes, but they are all made by the X-ES company.
Jean-Christophe is saying you should put your board in either:
board/devkit8000/or, if your company (embedinfo?) plans on adding more than just the devkit8000, put it in:
board/embedinfo/devkit8000 board/embedinto/<future_board_x>
I really dislike this. With OMAP3 this would result in something like
board/DigiKey/beagle (or board/TI/beagle?)
board/gumstix/overo
board/mistral/evm (or board/TI/evm? )
board/xx/pandora
board/zz/zoom1
board/yy/zoom2
etc.
Same for DaVinci.
After some time, or for somebody not familiar with it, it would be really hard to identify that all these are the same platform where grouping (and identifying common code) makes sense. It would pollute the number of directories in board even more.
Quoted 3 lines
I agree that other boards currently in board/omap3 should be moved to an appropriate board/<board vendor or board name> directory in the long run, ideally sooner rather than later:)
I disagree with this.
Having board/<board vendor or board name>
resulting in e.g.
board/embedinfo/devkit8000
board/embedinto/<future_board_x>
would result in a lot of more (unorganized) directories in board/* . I can't see any advantage in adding *more* directories into board/*. Instead, I see an advantage in having less directories in board/*, resulting in more organization/grouping.
Doing something like
board/ti/omap3
board/ti/omap2
board/ti/omap1
board/ti/davinci
would help to make board/* cleaner.
At the moment we have
board/omap3
board/davinci
what I feel is even better (cleaner) than what we would get with board/<board vendor or board name>
Quoted 3 lines
That being said, I think it
would make sense to put the devkit8000 in either board/devkit8000/ or board/embedinfo/devkit8000 now as that is the "correct" place for it.
Well, I just can't see what the advantage of this "correct" place might be. So from the rule point of view, it might make sense, but maybe we should adapt the rule, then?
Looking at the TI stuff, it seems to me that a lot of (small? different?) companies are using the same SoCs and doing boards with these. Most of the U-Boot code is similar, then. But these companies are doing only one or two boards. So it makes more sense to group these boards based on the SoC (vendor), instead of the board vendor or even worse the board name.
Best regards
Dirk
[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000
Hi Dirk,
Quoted 8 lines
Quoted 3 lines
That being said, I think it
would make sense to put the devkit8000 in either board/devkit8000/ or board/embedinfo/devkit8000 now as that is the "correct" place for it.Well, I just can't see what the advantage of this "correct" place might be. So from the rule point of view, it might make sense, but maybe we should adapt the rule, then?
Quoted 6 lines
Looking at the TI stuff, it seems to me that a lot of (small? different?) companies are using the same SoCs and doing boards with these. Most of the U-Boot code is similar, then. But these companies are doing only one or two boards. So it makes more sense to group these boards based on the SoC (vendor), instead of the board vendor or even worse the board name.
Well actually (I think) we agreed on doing the board/vendor scheme. For example look at board/amcc - there are all the AMCC evalboards basically each one with a different SoC. Turning this around into board/<soc> would throw pieces all over the places, which is definitely not what we want.
Let's look at it from this perspective - on a board level there is really more adhesion between two different cpu boards from one vendor than between two same cpu boards from different vendors. Just take the AMCC boards - they all have the same feel to them, so this is the natural way to group the boards.
Even more, sharing of stuff should be done outside of board/ - if it applies to all omap3, common stuff should be in cpu/arm_cortexa8/omap3 and *not at all* below board/.
Finding boards with the same architecture was always very easy by grepping the include/config/* files. We do not need a representation of this fact below board/.
Although I think that these arguments carry some value, I know that one can come up with - basically arbitrarily many other arguments. But still, we had this discussion already and I do not see that anything fundamental has changed since the last time around, so please let's not got into bike-shed painting right now ;)
Cheers
Detlev
Signature · 7 lines
["From 2.4 to 2.6 to 2.7" discussing release numbering of the Linux kernel]
Let the bike-shed-painting begin.
-- Linus Torvalds
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000
Hi Detlev,
Quoted 16 lines · Detlev Zundel
Hi Dirk,
Quoted 7 lines
Quoted 3 lines
That being said, I think it
would make sense to put the devkit8000 in either board/devkit8000/ or board/embedinfo/devkit8000 now as that is the "correct" place for it.Well, I just can't see what the advantage of this "correct" place might be. So from the rule point of view, it might make sense, but maybe we should adapt the rule, then?
Quoted 6 lines
Looking at the TI stuff, it seems to me that a lot of (small? different?) companies are using the same SoCs and doing boards with these. Most of the U-Boot code is similar, then. But these companies are doing only one or two boards. So it makes more sense to group these boards based on the SoC (vendor), instead of the board vendor or even worse the board name.
Quoted 5 lines
Well actually (I think) we agreed on doing the board/vendor scheme. For example look at board/amcc - there are all the AMCC evalboards basically each one with a different SoC. Turning this around into board/<soc> would throw pieces all over the places, which is definitely not what we want.
Yes, I agree that it makes no sense to *completely* change the rule.
Maybe we should just be a little bit more flexible about this rule and have look, where something else makes more sense.
Quoted 5 lines
Let's look at it from this perspective - on a board level there is really more adhesion between two different cpu boards from one vendor than between two same cpu boards from different vendors. Just take the AMCC boards - they all have the same feel to them, so this is the natural way to group the boards.
I could add the opposite example:
A <vendor == TI> OMAP3 based board (e.g. Beagle) has no adhesion with a <vendor == TI> DaVinci board.
Quoted 3 lines
Even more, sharing of stuff should be done outside of board/ - if it applies to all omap3, common stuff should be in cpu/arm_cortexa8/omap3 and *not at all* below board/.
Sounds like you propose to put omap3 *board* common stuff into *cpu* directory?
Quoted 3 lines
Finding boards with the same architecture was always very easy by grepping the
include/config/*files. We do not need a representation of this fact below board/.
But it wouldn't hurt?
Quoted 2 lines
Although I think that these arguments carry some value, I know that one can come up with - basically arbitrarily many other arguments.
Yes ;)
Quoted 4 lines
But
still, we had this discussion already and I do not see that anything fundamental has changed since the last time around, so please let's not got into bike-shed painting right now ;)
Could we agree to be more flexible with this rule?
Or, the other way around:
Independent of the rule, do you see any advantage of switching existing
board/omap3/
board/davinci/
into something like
board/DigiKey/beagle (or board/TI/beagle?)
board/gumstix/overo
board/mistral/evm (or board/TI/evm? )
board/xx/pandora
board/zz/zoom1
board/yy/zoom2
etc.?
Except to follow the rule?
Thanks
Dirk
[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000
Hi Dirk,
Quoted 10 lines
Quoted 5 lines
Well actually (I think) we agreed on doing the board/vendor scheme. For example look at board/amcc - there are all the AMCC evalboards basically each one with a different SoC. Turning this around into board/<soc> would throw pieces all over the places, which is definitely not what we want.
Yes, I agree that it makes no sense to *completely* change the rule.
Maybe we should just be a little bit more flexible about this rule and have look, where something else makes more sense.
I doubt that we can be more flexible with this rule without effectively introducing another rule. After all, that's what you say: "generally we follow rule a, only if it doesn't make sense (which one cannot tell beforehand) and then we follow rule b".
Such a "metarule" is not a big help - precisely because one cannot tell beforehand which "sub-rule" is applicable.
Quoted 10 lines
Quoted 5 lines
Let's look at it from this perspective - on a board level there is really more adhesion between two different cpu boards from one vendor than between two same cpu boards from different vendors. Just take the AMCC boards - they all have the same feel to them, so this is the natural way to group the boards.
I could add the opposite example:
A <vendor == TI> OMAP3 based board (e.g. Beagle) has no adhesion with a <vendor == TI> DaVinci board.
To which I reply - then TI should better shape up their U-Boot support and get the boards in line ;)
Quoted 6 lines
Quoted 3 lines
Even more, sharing of stuff should be done outside of board/ - if it applies to all omap3, common stuff should be in cpu/arm_cortexa8/omap3 and *not at all* below board/.
Sounds like you propose to put omap3 *board* common stuff into *cpu* directory?
No way. I only say that stuff which boards have in common *additional* to what they share from their architecture *should* be very little. Ideally a board/ directory is *very* light. The heavyweight stuff should be below cpu, drivers, etc.
Quoted 5 lines
Quoted 3 lines
Finding boards with the same architecture was always very easy by grepping the
include/config/*files. We do not need a representation of this fact below board/.But it wouldn't hurt?
It hurts if it stops us from having a single rule.
Quoted 22 lines
Quoted 3 lines
But still, we had this discussion already and I do not see that anything fundamental has changed since the last time around, so please let's not got into bike-shed painting right now ;)
Could we agree to be more flexible with this rule?
Or, the other way around:
Independent of the rule, do you see any advantage of switching existing
board/omap3/
board/davinci/into something like
board/DigiKey/beagle (or board/TI/beagle?)
board/gumstix/overo
board/mistral/evm (or board/TI/evm? )
board/xx/pandora
board/zz/zoom1
board/yy/zoom2
Quoted 3 lines
etc.?
Except to follow the rule?
A rule is only good if it really helps to organize stuff. So yes, I see an advantage of the latter examples, namely that someone looking into board/ has a single rule which will allow him to find what he is looking for.
Cheers
Detlev
Signature · 6 lines
I talk to planets baby
-- Dave Wyndorf (Monstermagnet)
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000
In reply to Dirk BehmeDear Dirk Behme,
Quoted 5 lines · In message <[email protected]> you wrote:
I could add the opposite example:
A <vendor == TI> OMAP3 based board (e.g. Beagle) has no adhesion with a <vendor == TI> DaVinci board.
I tend to interpret this as poor board support by that vendor, then.
A vendor who has several boards to suuport, does himself and especially all his users a big fevour if he implements a common look and feel - compare what boards manufactured for example by AMCC, Freescale (at least more recent ports) or TQ are doing (alphabetical oder, in case you did not notice) - they try to provide a similar setup of their environment variables, etc. - no matter which actual processor or SoC a board may be based on.
It is intentional that the current directury struxcture supports this.
Quoted 2 lines
Sounds like you propose to put omap3 *board* common stuff into *cpu* directory?
If _all_ OMAP3 boards share this stuff, then t i indeed not board common, but CPU coomon, and should go into the CPU directory. Well spotted.
Quoted 5 lines
Quoted 3 lines
Finding boards with the same architecture was always very easy by grepping the
include/config/*files. We do not need a representation of this fact below board/.But it wouldn't hurt?
Yes, it would, It would disrupt order.
Quoted 1 line
Could we agree to be more flexible with this rule?
No. :-)
Quoted 5 lines
Independent of the rule, do you see any advantage of switching existing
board/omap3/
board/davinci/
Quoted 8 lines
into something like
board/DigiKey/beagle (or board/TI/beagle?)
board/gumstix/overo
board/mistral/evm (or board/TI/evm? )
board/xx/pandora
board/zz/zoom1
board/yy/zoom2
That should indeed be board/TI/beagle, board/TI/evm, if TI is the board vendor.
Quoted 1 line
Except to follow the rule?
Yes, please follow the rules :-)
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de I can type faster than I can move a mouse, so I find menu-driven drawing packages time consuming and frustrating. - W. R. Stevens
[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000
In reply to Detlev ZundelDear Detlev Zundel,
Quoted 16 lines · In message <[email protected]> you wrote:
Quoted 9 lines
Quoted 4 lines
That being said, I think it
would make sense to put the devkit8000 in either board/devkit8000/ or board/embedinfo/devkit8000 now as that is the "correct" place for it.Well, I just can't see what the advantage of this "correct" place might be. So from the rule point of view, it might make sense, but maybe we should adapt the rule, then?
Quoted 6 lines
Looking at the TI stuff, it seems to me that a lot of (small? different?) companies are using the same SoCs and doing boards with these. Most of the U-Boot code is similar, then. But these companies are doing only one or two boards. So it makes more sense to group these boards based on the SoC (vendor), instead of the board vendor or even worse the board name.
Quoted 5 lines
Well actually (I think) we agreed on doing the board/vendor scheme. For example look at board/amcc - there are all the AMCC evalboards basically each one with a different SoC. Turning this around into board/<soc> would throw pieces all over the places, which is definitely not what we want.
Correct. That's the cuirrent "official" definiiton, and so far I see no reason to change it.
Quoted 5 lines
Although I think that these arguments carry some value, I know that one can come up with - basically arbitrarily many other arguments. But still, we had this discussion already and I do not see that anything fundamental has changed since the last time around, so please let's not got into bike-shed painting right now ;)
Full ACK.
We have a pretty clear definition, and I see no reason to change this.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Pig: An animal (Porcus omnivorous) closely allied to the human race by the splendor and vivacity of its appetite, which, however, is in- ferior in scope, for it balks at pig. - Ambrose Bierce
[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000
Quoted 17 lines · Wolfgang Denk
Quoted 16 lines · In message <[email protected]> you wrote:
Quoted 15 lines
Quoted 4 lines
That being said, I think it
would make sense to put the devkit8000 in either board/devkit8000/ or board/embedinfo/devkit8000 now as that is the "correct" place for it.Well, I just can't see what the advantage of this "correct" place might be. So from the rule point of view, it might make sense, but maybe we should adapt the rule, then?
Looking at the TI stuff, it seems to me that a lot of (small? different?) companies are using the same SoCs and doing boards with these. Most of the U-Boot code is similar, then. But these companies are doing only one or two boards. So it makes more sense to group these boards based on the SoC (vendor), instead of the board vendor or even worse the board name.
Quoted 8 lines
Quoted 5 lines
Well actually (I think) we agreed on doing the board/vendor scheme. ?For example look at board/amcc - there are all the AMCC evalboards basically each one with a different SoC. ?Turning this around into board/<soc> would throw pieces all over the places, which is definitely not what we want.
Correct. That's the cuirrent "official" definiiton, and so far I see no reason to change it.
Ok, is there a official naming convention for the include/configs/*.h files and the *_config targets? Should they be grouped by CPU/SoC and/or vendor (Makefile/MAKEALL)?
[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000
Dear Frederik Kriewitz,
Quoted 4 lines · In message <[email protected]> you…
Ok, is there a official naming convention for the
include/configs/*.hfiles and the*_configtargets? Should they be grouped by CPU/SoC and/or vendor (Makefile/MAKEALL)?
There is no such convention except that *_config targets are expected to use lower case characters only. We try to match the real product names as close as possible so everybody is able to recognize "his" board. The only grouping done in Makefilke and Makeall is by CPU architecture (i. e. ARM9, ARM11, ARM_CORTEX_A8, ... 4xx, 83xx, ...) etc. Within each group, lists are sorted alphabetically (ignoring case).
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "One planet is all you get."
[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000
In reply to Dirk BehmeHi Dirk,
Quoted 25 lines
Quoted 4 lines
My understanding is that the board/ layout should be "/board/<board vendor or board name>/...". So even though the Frederik's board has a TI OMAP3 cpu, he shouldn't put it in board/ti or board/omap3 since neither TI nor OMAP3 made the DevKit8000.
...
Quoted 10 lines
For example, there are mpc8548, mpc8572, mpc8548, and amcc440-based boards in board/xes, but they are all made by the X-ES company.
Jean-Christophe is saying you should put your board in either:
board/devkit8000/or, if your company (embedinfo?) plans on adding more than just the devkit8000, put it in:
board/embedinfo/devkit8000 board/embedinto/<future_board_x>I really dislike this. With OMAP3 this would result in something like
board/DigiKey/beagle (or board/TI/beagle?)
board/gumstix/overo
board/mistral/evm (or board/TI/evm? )
board/xx/pandora
board/zz/zoom1
board/yy/zoom2
Quoted 8 lines
etc.
Same for DaVinci.
After some time, or for somebody not familiar with it, it would be really hard to identify that all these are the same platform where grouping (and identifying common code) makes sense. It would pollute the number of directories in board even more.
I don't think most end users care much about which boards correlate to which platform - they care about where the board they are currently working with is located in the U-Boot tree. From this perspective, I think board/<vendor> makes sense. Eg I'm working on an X-ES board, I'll look in board/xes, I'm working on a Freescale reference platform, I look in board/freescale.
Quoted 18 lines
Quoted 3 lines
I agree that other boards currently in board/omap3 should be moved to an appropriate board/<board vendor or board name> directory in the long run, ideally sooner rather than later:)
I disagree with this.
Having board/<board vendor or board name>
resulting in e.g.
board/embedinfo/devkit8000
board/embedinto/<future_board_x>would result in a lot of more (unorganized) directories in board/* . I can't see any advantage in adding *more* directories into board/*. Instead, I see an advantage in having less directories in board/*, resulting in more organization/grouping.
Quoted 8 lines
Doing something like
board/ti/omap3
board/ti/omap2
board/ti/omap1
board/ti/davinciwould help to make board/* cleaner.
I think its a matter of opinion. Some companies support many different cpu architectures. I like having our X-ES-specific code in 1 location, board/xes. X-ES boards can then easily share common code too, eg board/xes/common/. Where would vendor-specific code that was used on multiple boards be located if the board/<vendor> layout is not used? The alternative is something like:
board/freescale/mpc85xx/xpedite5370/
board/freescale/mpc86xx/xpedite5170/
board/amcc/ppc44x/xpedite1000/
<somewhere else?>/xes-common/
This seems more disorganized than board/xes to me.
Quoted 7 lines
At the moment we have
board/omap3
board/davinciwhat I feel is even better (cleaner) than what we would get with board/<board vendor or board name>
I think this breaks down (or at least is less appealing) when a board vendor supports a number of different cpus and has some code that is shared between their boards.
Quoted 8 lines
Quoted 3 lines
That being said, I think it
would make sense to put the devkit8000 in either board/devkit8000/ or board/embedinfo/devkit8000 now as that is the "correct" place for it.Well, I just can't see what the advantage of this "correct" place might be. So from the rule point of view, it might make sense, but maybe we should adapt the rule, then?
Quoted 6 lines
Looking at the TI stuff, it seems to me that a lot of (small? different?) companies are using the same SoCs and doing boards with these. Most of the U-Boot code is similar, then. But these companies are doing only one or two boards. So it makes more sense to group these boards based on the SoC (vendor), instead of the board vendor or even worse the board name.
I can see that angle, but I can see other angles too. I'd lean towards the current layout (technically how the PPC boards are currently organized), but if you had a good solution for us vendors that support a number of different CPUs and have some common vendor code, it'd be interesting to discuss.
Best,
Peter