Separate EBV Socrates board from Altera Cyclone 5 board

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Quoted 5 lines · Pavel Machek

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Quoted 5 lines

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Is there any way at run time to tell which board we are on?

Quoted 11 lines · Pavel Machek

Quoted 10 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Quoted 3 lines

Quoted 1 line

Signed-off-by Pavel Machek <[email protected]>

Is there any way at run time to tell which board we are on?

Why do you care about board name in general?

Hi Michal,

Quoted 16 lines · Tom Rini

Quoted 14 lines · Pavel Machek

Quoted 11 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Is there any way at run time to tell which board we are on?

Quoted 1 line

Why do you care about board name in general?

We care for board names for a very long time in U-Boot and I'd like to keep this. I actually expect a sensible board name on any platform that I touch. The board name is an important extra information additional to the SoC name. So the question is the other way round - since when do we _not_ care about board names?

Quoted 18 lines · Detlev Zundel

Hi Michal,

Quoted 16 lines · Tom Rini

Quoted 14 lines · Pavel Machek

Quoted 11 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Is there any way at run time to tell which board we are on?

Quoted 7 lines

Quoted 1 line

Why do you care about board name in general?

We care for board names for a very long time in U-Boot and I'd like to keep this. I actually expect a sensible board name on any platform that I touch. The board name is an important extra information additional to the SoC name. So the question is the other way round - since when do we _not_ care about board names?

There could be i2c memory on board where you can find out this information but that's problematic if it is empty or you want to use this i2c for something else. For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design (if user is smart enough board name is the part of hw design name).
For zynq/socfpga sensible solution is probably to load this name for DTS.

Thanks,
Michal

Hi all,

Quoted 27 lines · Michal Simek

Quoted 18 lines · Detlev Zundel

Hi Michal,

Quoted 16 lines · Tom Rini

Quoted 14 lines · Pavel Machek

Quoted 11 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Is there any way at run time to tell which board we are on?

Quoted 7 lines

Quoted 1 line

Why do you care about board name in general?

We care for board names for a very long time in U-Boot and I'd like to keep this. I actually expect a sensible board name on any platform that I touch. The board name is an important extra information additional to the SoC name. So the question is the other way round - since when do we _not_ care about board names?

Quoted 6 lines

There could be i2c memory on board where you can find out this information but that's problematic if it is empty or you want to use this i2c for something else. For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design (if user is smart enough board name is the part of hw design name).
For zynq/socfpga sensible solution is probably to load this name for DTS.

Currently, the SOCFPGA SPL is customized through a set of handoff files which located at board folders. These handoff files are generated by tools based on board and user design in FPGA. With that, not much decision being made during run time based on the board. With this handoff and tools approach, it will shield off the complexity of hardware configuration and errors (if user change it manually without tools help). Thanks

Quoted 11 lines · Chin Liang See

Hi all,

Quoted 8 lines · Michal Simek

Quoted 7 lines · Detlev Zundel

Hi Michal,

Quoted 5 lines · Tom Rini

Quoted 4 lines · Pavel Machek

Quoted 3 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board.

Different

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they

are

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Is there any way at run time to tell which board we are on?

Why do you care about board name in general?

We care for board names for a very long time in U-Boot and I'd like to keep this. I actually expect a sensible board name on any platform

that

Quoted 1 line

Quoted 1 line

Quoted 1 line

I touch. The board name is an important extra information additional

to

Quoted 1 line

Quoted 1 line

Quoted 1 line

the SoC name. So the question is the other way round - since when do

we

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

_not_ care about board names?

There could be i2c memory on board where you can find out this

information but that's

Quoted 1 line

Quoted 1 line

problematic if it is empty or you want to use this i2c for something

else.

Quoted 1 line

Quoted 1 line

For all microblaze boards I use XILINX_BOARD_NAME which reflects hw

design

Quoted 2 lines

Quoted 2 lines

(if user is smart enough board name is the part of hw design name). For zynq/socfpga sensible solution is probably to load this name for

DTS.

Quoted 9 lines

Quoted 1 line

Currently, the SOCFPGA SPL is customized through a set of handoff files which located at board folders. These handoff files are generated by tools based on board and user design in FPGA. With that, not much decision being made during run time based on the board. With this handoff and tools approach, it will shield off the complexity of hardware configuration and errors (if user change it manually without tools help). Thanks

Which nice copy of our approach. :-)

But anyway I believe that you are also generating one macro which define name of this configuration based on hw design/board you are using. And then you can use this macro for showing board/design name in u-boot.

Thanks,
Michal

--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 37 lines · Chin Liang See

Hi all,

Quoted 27 lines · Michal Simek

Quoted 18 lines · Detlev Zundel

Hi Michal,

Quoted 16 lines · Tom Rini

Quoted 14 lines · Pavel Machek

Quoted 11 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Is there any way at run time to tell which board we are on?

Quoted 7 lines

Quoted 1 line

Why do you care about board name in general?

We care for board names for a very long time in U-Boot and I'd like to keep this. I actually expect a sensible board name on any platform that I touch. The board name is an important extra information additional to the SoC name. So the question is the other way round - since when do we _not_ care about board names?

Quoted 6 lines

There could be i2c memory on board where you can find out this information but that's problematic if it is empty or you want to use this i2c for something else. For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design (if user is smart enough board name is the part of hw design name).
For zynq/socfpga sensible solution is probably to load this name for DTS.

Quoted 7 lines

Currently, the SOCFPGA SPL is customized through a set of handoff files which located at board folders. These handoff files are generated by tools based on board and user design in FPGA. With that, not much decision being made during run time based on the board. With this handoff and tools approach, it will shield off the complexity of hardware configuration and errors (if user change it manually without tools help). Thanks

Which nice copy of our approach. :-)

But anyway I believe that you are also generating one macro which define name of this configuration based on hw design/board you are using. And then you can use this macro for showing board/design name in u-boot.

Thanks,
Michal

Quoted 46 lines · Michal Simek

Quoted 44 lines · Chin Liang See

Hi all,

Quoted 27 lines · Michal Simek

Quoted 18 lines · Detlev Zundel

Hi Michal,

Quoted 16 lines · Tom Rini

Quoted 14 lines · Pavel Machek

Quoted 11 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Is there any way at run time to tell which board we are on?

Quoted 7 lines

Quoted 1 line

Why do you care about board name in general?

We care for board names for a very long time in U-Boot and I'd like to keep this. I actually expect a sensible board name on any platform that I touch. The board name is an important extra information additional to the SoC name. So the question is the other way round - since when do we _not_ care about board names?

Quoted 6 lines

There could be i2c memory on board where you can find out this information but that's problematic if it is empty or you want to use this i2c for something else. For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design (if user is smart enough board name is the part of hw design name).
For zynq/socfpga sensible solution is probably to load this name for DTS.

Currently, the SOCFPGA SPL is customized through a set of handoff files which located at board folders. These handoff files are generated by tools based on board and user design in FPGA. With that, not much decision being made during run time based on the board. With this handoff and tools approach, it will shield off the complexity of hardware configuration and errors (if user change it manually without tools help). Thanks

Quoted 1 line

Which nice copy of our approach. :-)

Hmmm... is it true? This approach being used since few years back at NIOS soft processor. Besides that, we are utilizing the SPL framework for our second stage boot loader. I believe you guys are not using SPL right? It seems you guys would need tools to generate and even build you guys own version of boot loader. It creates high dependency for user to your tools.

For our solution, customer can just grab the code from git and build it using the normal U-Boot way (if they don't want to use the tools). With the SPL also, we are taking advantage of open source community power to make our second stage boot loader more powerful and user friendly to user. Our user can grab any drivers or leverage the supports from the open community too. I believe that is the power of open source :)

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Quoted 1 line

Currently, the SOCFPGA SPL is customized through a set of handoff files which located at board folders. These handoff files are generated by tools based on board and user design in FPGA. With that, not much decision being made during run time based on the board. With this handoff and tools approach, it will shield off the complexity of hardware configuration and errors (if user change it manually without tools help). Thanks

Quoted 8 lines

Quoted 1 line

Which nice copy of our approach. :-)

Hmmm... is it true? This approach being used since few years back at NIOS soft processor. Besides that, we are utilizing the SPL framework for our second stage boot loader. I believe you guys are not using SPL right? It seems you guys would need tools to generate and even build you guys own version of boot loader. It creates high dependency for user to your tools.

Interesting discussion. :-)
I believe we will use SPL at some point in future for Microblaze just because of easier maintenance . But will see.

I don't understand your point regarding to tool dependency. For DTSes I believe you are also generating this structure from design tools or you can write it by hand.
We are also generating U-boot configuration but if someone wants to write it by hand they can.

Quoted 6 lines

For our solution, customer can just grab the code from git and build it using the normal U-Boot way (if they don't want to use the tools). With the SPL also, we are taking advantage of open source community power to make our second stage boot loader more powerful and user friendly to user. Our user can grab any drivers or leverage the supports from the open community too. I believe that is the power of open source :)

We have the same for Microblaze and Zynq.

Cheers,
Michal

Hi,

Quoted 19 lines

Quoted 18 lines

Quoted 11 lines

Quoted 9 lines

Quoted 1 line

Currently, the SOCFPGA SPL is customized through a set of handoff files which located at board folders. These handoff files are generated by tools based on board and user design in FPGA. With that, not much decision being made during run time based on the board. With this handoff and tools approach, it will shield off the complexity of hardware configuration and errors (if user change it manually without tools help). Thanks

Which nice copy of our approach. :-)

Hmmm... is it true? This approach being used since few years back at NIOS soft processor. Besides that, we are utilizing the SPL framework for our second stage boot loader. I believe you guys are not using SPL right? It seems you guys would need tools to generate and even build you guys own version of boot loader. It creates high dependency for user to your tools.

Quoted 3 lines

Interesting discussion. :-)
I believe we will use SPL at some point in future for Microblaze just because of easier maintenance . But will see.

Yup, utilizing SPL will gain you the power of open source :)

Quoted 6 lines

I don't understand your point regarding to tool dependency. For DTSes I believe you are also generating this structure from design tools or you can write it by hand.
We are also generating U-boot configuration but if someone wants to write it by hand they can.

I believe we have misalignment on the term used. For us, second stage bootloader is referring to the bootloader loaded by BootROM. I believe you guys are referring that as FSBL.

Quoted 7 lines

Quoted 6 lines

For our solution, customer can just grab the code from git and build it using the normal U-Boot way (if they don't want to use the tools). With the SPL also, we are taking advantage of open source community power to make our second stage boot loader more powerful and user friendly to user. Our user can grab any drivers or leverage the supports from the open community too. I believe that is the power of open source :)

Quoted 1 line

We have the same for Microblaze and Zynq.

Same as above, I believe both of us are using U-Boot. But for bootloader before U-Boot, we are using SPL while you guys using FSBL which is not SPL framework, right? With that, I believe you guys would need a proprietary tools to compile and build the FSBL. We would not have this dependency when building the SPL code.

Hi Michal,

Quoted 16 lines · Tom Rini

Quoted 14 lines · Pavel Machek

Quoted 11 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Is there any way at run time to tell which board we are on?

Quoted 1 line

Why do you care about board name in general?

We care for board names for a very long time in U-Boot and I'd like to keep this. I actually expect a sensible board name on any platform that I touch. The board name is an important extra information additional to the SoC name. So the question is the other way round - since when do we _not_ care about board names?

Quoted 6 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Quoted 5 lines

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Is there any way at run time to tell which board we are on?

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users. Virtual target is completely different, and board configured for it will not boot on physical targets.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

---

Diff from v1: separate virtual target, too, and make it apply to recent u-boot.

board/altera/socfpga/socfpga_cyclone5.c +1 -1

index a960eb6..33946b6 100644
@@ -28,7 +28,7 @@ int print_cpuinfo(void)
  */
 int checkboard(void)
 {
-	puts("BOARD : Altera SOCFPGA Cyclone5 Board\n");
+	puts("BOARD : " ALTERA_BOARD_NAME "\n");
 	return 0;
 }
 

boards.cfg +0 -0

index 221b7f8..6eebbf5 100644

Quoted 6 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users. Virtual target is completely different, and board configured for it will not boot on physical targets.

Thanks for the initiative again.

boards.cfg Active arm armv7 rmobile renesas lager · line 383

Quoted 8 lines

boards.cfg +2 -0

@@ -379,6 +379,8 @@ Active  arm         armv7          rmobile     renesas         lager
 Active  arm         armv7          s5pc1xx     samsung         goni                s5p_goni                              -                                                                                                                                 Przemyslaw Marczak <[email protected]>
 Active  arm         armv7          s5pc1xx     samsung         smdkc100            smdkc100                              -                                                                                                                                 Minkyu Kang <[email protected]>
 Active  arm         armv7          socfpga     altera          socfpga             socfpga_cyclone5                      -                                                                                                                                 -
+Active  arm         armv7          socfpga     altera          socfpga             socfpga_virtual                      -                                                                                                                                 -
+Active  arm         armv7          socfpga     altera          socfpga             socfpga_socrates

As you correctly note, the socrates is sold by EBV and not Altera so I guess the 5th column needs to be changed. Will this still work?

Hi, Detlev!

Quoted 7 lines

Quoted 6 lines

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users. Virtual target is completely different, and board configured for it will not boot on physical targets.

Quoted 1 line

Thanks for the initiative again.

I'm celebrating mainline u-boot on my target :-).

Quoted 5 lines

Quoted 5 lines

boards.cfg +0 -0

@@ -379,6 +379,8 @@ Active arm armv7 rmobile renesas lager
 Active arm armv7 s5pc1xx samsung goni s5p_goni - Przemyslaw

Marczak <[email protected]>

Quoted 8 lines

boards.cfg

Quoted 5 lines

Active arm armv7 s5pc1xx samsung smdkc100 smdkc100 - Minkyu Kang
<[email protected]>
Active arm armv7 socfpga altera socfpga socfpga_cyclone5 - -

boards.cfg +2 -0

+Active arm armv7 socfpga altera socfpga socfpga_virtual - -
+Active arm armv7 socfpga altera socfpga socfpga_socrates

As you correctly note, the socrates is sold by EBV and not Altera so I guess the 5th column needs to be changed. Will this still work?

That will result in:

CC arch/arm/lib/eabi_compat.o
scripts/Makefile.build:64:
/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile: No such file or directory
make[2]: *** No rule to make target `/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile'. Stop.

...and I don't think we want to do board/{altera,ebv} symlink. Are there any other options? Or is "altera" in the boards file simply acceptable?

Quoted 4 lines

/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile: No such file or directory
make[2]: *** No rule to make target `/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile'. Stop.

I feared as much, so thats why I asked ;)

Quoted 3 lines

...and I don't think we want to do board/{altera,ebv} symlink. Are there any other options? Or is "altera" in the boards file simply acceptable?

This is a problem that will turn up in the future even more, so I propose to solve it correctly now. It will not be long before we want

to have our own configuration for our MCV module and this will certainly be sold by DENX. I think we need an infrastructure to allow for boards sold by arbitrary manufacturers all using the Altera chip.

The situation as such is not uncommon, so maybe you can follow examples from different CPUs? I.e. how is the imx6 handled on the different base boards?

Hi!

Quoted 11 lines

Quoted 4 lines

/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile: No such file or directory
make[2]: *** No rule to make target `/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile'. Stop.

I feared as much, so thats why I asked ;)

Quoted 3 lines

...and I don't think we want to do board/{altera,ebv} symlink. Are there any other options? Or is "altera" in the boards file simply acceptable?

Quoted 3 lines

This is a problem that will turn up in the future even more, so I propose to solve it correctly now. It will not be long before we want

Well, OTOH it is orthogonal problem to the "board name is shared between socrates and altera" and "config is shared between altera and virtual target". And this patch is going to go stale rather quickly.

Quoted 7 lines

to have our own configuration for our MCV module and this will certainly be sold by DENX. I think we need an infrastructure to allow for boards sold by arbitrary manufacturers all using the Altera chip.

The situation as such is not uncommon, so maybe you can follow examples from different CPUs? I.e. how is the imx6 handled on the different base boards?

The examples I seen were different: there different board vendors actually needed different code.

AFAICT, one solution would be to put "-" in that column, and do "git mv board/altera/ board/socfpga/".

But if we decide to go that way, it should really be separate patch.

Quoted 3 lines

Well, OTOH it is orthogonal problem to the "board name is shared between socrates and altera" and "config is shared between altera and virtual target". And this patch is going to go stale rather quickly.

I admit, I do not understand that fully.

Quoted 8 lines

Quoted 7 lines

to have our own configuration for our MCV module and this will certainly be sold by DENX. I think we need an infrastructure to allow for boards sold by arbitrary manufacturers all using the Altera chip.

The situation as such is not uncommon, so maybe you can follow examples from different CPUs? I.e. how is the imx6 handled on the different base boards?

Quoted 5 lines

The examples I seen were different: there different board vendors actually needed different code.

AFAICT, one solution would be to put "-" in that column, and do "git mv board/altera/ board/socfpga/".

Putting "-" in the vendor column just doesn't feel right.

How about
using a minimal board C file for socrates under ebv/socrates that only implements checkboard and shares the rest?

Quoted 1 line

But if we decide to go that way, it should really be separate patch.

I still like to see a solution that scales to things we already know will happen ;) Looking at the original patch, with this in mind even the #define ALTERA_BOARD_NAME doesn't look right any longer.

There are no differences between EBV socrates and socfpga boards, currently.

Quoted 4 lines

Quoted 2 lines

AFAICT, one solution would be to put "-" in that column, and do "git mv board/altera/ board/socfpga/".

Putting "-" in the vendor column just doesn't feel right.

That's what mx6 did, AFAICT.

Actually.. there's nothing Altera specific in board/altera (it works on ebv just fine), so board/socfpga sounds like a better name. But I don't think such rename should be done lightly, so I still believe the patch as submitted is the best way to go.

Quoted 3 lines · In message <[email protected]> you wrote:

There are no differences between EBV socrates and socfpga boards, currently.

Well, for one thing, the board vendor and the board name differ...

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

AFAICT, one solution would be to put "-" in that column, and do "git mv board/altera/ board/socfpga/".

Putting "-" in the vendor column just doesn't feel right.

That's what mx6 did, AFAICT.

I think Detlev is right here. We do have specific board vendors directories, and there are a number of reasons to keep this used (just to give one example: say a vendor wants to use a similar look and feel for the default environment settings etc. for all boards).

If there is code which is identical for several (or all?) boards we should ask ourself if it really belongs into the board/ directory at all?

Quoted 4 lines

Actually.. there's nothing Altera specific in board/altera (it works on ebv just fine), so board/socfpga sounds like a better name. But I don't think such rename should be done lightly, so I still believe the patch as submitted is the best way to go.

I think board/altera as such makes sense, with Altera being the vendor of that specific board. However, if there is common code there, this code should be moved out of board/ .

Quoted 6 lines

Quoted 3 lines · In message <[email protected]> you wrote:

There are no differences between EBV socrates and socfpga boards, currently.

Well, for one thing, the board vendor and the board name differ...

I meant from current code in u-boot point of view...

Quoted 12 lines

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

AFAICT, one solution would be to put "-" in that column, and do "git
mv board/altera/ board/socfpga/".

Putting "-" in the vendor column just doesn't feel right.

That's what mx6 did, AFAICT.

I think Detlev is right here. We do have specific board vendors directories, and there are a number of reasons to keep this used (just to give one example: say a vendor wants to use a similar look and feel for the default environment settings etc. for all boards).

Quoted 3 lines

If there is code which is identical for several (or all?) boards we should ask ourself if it really belongs into the board/ directory at all?

That might be the case. It seems that current code in board/altera is SoC-specific, as it works on both Altera and EBV boards.

Quoted 5 lines

Quoted 4 lines

Actually.. there's nothing Altera specific in board/altera (it works on ebv just fine), so board/socfpga sounds like a better name. But I don't think such rename should be done lightly, so I still believe the patch as submitted is the best way to go.

Quoted 3 lines

I think board/altera as such makes sense, with Altera being the vendor of that specific board. However, if there is common code there, this code should be moved out of board/ .

It seems there's currently 99.99% of SoC-specific code there.

What would be the right place for that code?

arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific. drivers/misc ? Do we need to make a soc/ directory?

And then... who does the move? It is not going to make merging between rocketboards.org and mainline even trickier than it already is :-(.

Hi Pavel,

Quoted 3 lines · Wolfgang Denk

Quoted 2 lines

Quoted 1 line · In message <[email protected]> you wrote:

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

There are no differences between EBV socrates and socfpga boards, currently.

Well, for one thing, the board vendor and the board name differ...

I meant from current code in u-boot point of view...

But as we all agree, this may change quickly and for multiple boards.

Quoted 14 lines

Quoted 13 lines

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

AFAICT, one solution would be to put "-" in that column, and do "git
mv board/altera/ board/socfpga/".

Putting "-" in the vendor column just doesn't feel right.

That's what mx6 did, AFAICT.

I think Detlev is right here. We do have specific board vendors directories, and there are a number of reasons to keep this used (just to give one example: say a vendor wants to use a similar look and feel for the default environment settings etc. for all boards).

Quoted 6 lines

Quoted 3 lines

If there is code which is identical for several (or all?) boards we should ask ourself if it really belongs into the board/ directory at all?

That might be the case. It seems that current code in board/altera is SoC-specific, as it works on both Altera and EBV boards.

Then we are in agreement that it does not belong below board/ ;)

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

Actually.. there's nothing Altera specific in board/altera (it works on ebv just fine), so board/socfpga sounds like a better name. But I don't think such rename should be done lightly, so I still believe the patch as submitted is the best way to go.

Quoted 7 lines

Quoted 3 lines

I think board/altera as such makes sense, with Altera being the vendor of that specific board. However, if there is common code there, this code should be moved out of board/ .

It seems there's currently 99.99% of SoC-specific code there.

What would be the right place for that code?

Depends on what exactly it implements. Apart from that we can also take a look at where the code is in a Linux tree and take that as an example. After all, we want people developing the Linux kernel to also feel at home in the U-Boot sources.

Quoted 2 lines

arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific. drivers/misc ? Do we need to make a soc/ directory?

We have arch/arm/imx-common for example, but I'm not so sure if this is a good approach. Maybe there is not a _single_ correct place, but we have to distribute the files to multiple directories?

Quoted 2 lines

And then... who does the move? It is not going to make merging between rocketboards.org and mainline even trickier than it already is :-(.

This is a good question and we should certainly not answer it lightly. Usually we care only to a certain degree for non-mainline code, though. Blocking ourselves because of non-mainline code would allow "external" control which I think is not really helpful for the project.

Cheers
Detlev

Hi guys,

Quoted 12 lines · Detlev Zundel

Hi Pavel,

Quoted 9 lines · Wolfgang Denk

Quoted 6 lines

Quoted 3 lines · In message <[email protected]> you wrote:

There are no differences between EBV socrates and socfpga boards, currently.

Well, for one thing, the board vendor and the board name differ...

I meant from current code in u-boot point of view...

Quoted 1 line

But as we all agree, this may change quickly and for multiple boards.

Yup, some other board vendors are using different HW configuration. Some of the difference are Altera dev kit have EEPROM and using Micrel PHY for EMAC. I presume Socrates board should have their own board path such as board/socrates/socfpga.

Quoted 13 lines

Quoted 13 lines

Quoted 12 lines

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

AFAICT, one solution would be to put "-" in that column, and do "git
mv board/altera/ board/socfpga/".

Putting "-" in the vendor column just doesn't feel right.

That's what mx6 did, AFAICT.

I think Detlev is right here. We do have specific board vendors directories, and there are a number of reasons to keep this used (just to give one example: say a vendor wants to use a similar look and feel for the default environment settings etc. for all boards).

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

If there is code which is identical for several (or all?) boards we should ask ourself if it really belongs into the board/ directory at all?

That might be the case. It seems that current code in board/altera is SoC-specific, as it works on both Altera and EBV boards.

Then we are in agreement that it does not belong below board/ ;)

Within board/altera, there are 2 types of files as below:

1. HW configuration handoff files (such as pinmux_config, pll_config). Pinmux might be different as certain board might have different
routing (normally to optimize the board layout and shorter PCB trace length).

2. Board specific code (socfpga_cyclone5.c)
These functions include board_init, board_early_init, checkboard. I believe that the function print_cpuinfo and overwrite _console
should goto arch/arm/cpu/armv7/socfpga/misc.c.
I will create the patch to change this later (as I already did this
at rocketboard.org).

Quoted 25 lines

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Actually.. there's nothing Altera specific in board/altera (it works on ebv just fine), so board/socfpga sounds like a better name. But I don't think such rename should be done lightly, so I still believe the patch as submitted is the best way to go.

Quoted 7 lines

Quoted 3 lines

I think board/altera as such makes sense, with Altera being the vendor of that specific board. However, if there is common code there, this code should be moved out of board/ .

It seems there's currently 99.99% of SoC-specific code there.

What would be the right place for that code?

Depends on what exactly it implements. Apart from that we can also take a look at where the code is in a Linux tree and take that as an example. After all, we want people developing the Linux kernel to also feel at home in the U-Boot sources.

Quoted 2 lines

arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific. drivers/misc ? Do we need to make a soc/ directory?

We have arch/arm/imx-common for example, but I'm not so sure if this is a good approach. Maybe there is not a _single_ correct place, but we have to distribute the files to multiple directories?

Quoted 8 lines

Quoted 2 lines

And then... who does the move? It is not going to make merging between rocketboards.org and mainline even trickier than it already is :-(.

This is a good question and we should certainly not answer it lightly. Usually we care only to a certain degree for non-mainline code, though. Blocking ourselves because of non-mainline code would allow "external" control which I think is not really helpful for the project.

As above, I can move some common function to
arch/arm/cpu/armv7/socfpga/misc.c.

Altera Cyclone 5 board is very different board (big, rectangular, expensive) than EBV Socrates (small, circular, cheap) board. Different parts are used there, too, but same configuration of u-boot works on both. Nevertheless, printing wrong name confuses users. Virtual target is completely different, and board configured for it will not boot on physical targets.

Therefore this splits the configuration so that u-boot knows they are different. So far it is only used for correcting the puts, but there may be other uses in future.

Signed-off-by Pavel Machek <[email protected]>

---

Diff from v1: separate virtual target, too, and make it apply to recent u-boot.

board/altera/socfpga/socfpga_cyclone5.c +1 -1

index a960eb6..33946b6 100644
@@ -28,7 +28,7 @@ int print_cpuinfo(void)
  */
 int checkboard(void)
 {
-	puts("BOARD : Altera SOCFPGA Cyclone5 Board\n");
+	puts("BOARD : " ALTERA_BOARD_NAME "\n");
 	return 0;
 }
 

boards.cfg +2 -0

index 221b7f8..6eebbf5 100644
@@ -379,6 +379,8 @@ Active  arm         armv7          rmobile     renesas         lager
 Active  arm         armv7          s5pc1xx     samsung         goni                s5p_goni                              -                                                                                                                                 Przemyslaw Marczak <[email protected]>
 Active  arm         armv7          s5pc1xx     samsung         smdkc100            smdkc100                              -                                                                                                                                 Minkyu Kang <[email protected]>
 Active  arm         armv7          socfpga     altera          socfpga             socfpga_cyclone5                      -                                                                                                                                 -
+Active  arm         armv7          socfpga     altera          socfpga             socfpga_virtual                      -                                                                                                                                 -
+Active  arm         armv7          socfpga     altera          socfpga             socfpga_socrates                      -                                                                                                                                 -
 Active  arm         armv7          u8500       st-ericsson     snowball            snowball                              -                                                                                                                                 Mathieu Poirier <[email protected]>
 Active  arm         armv7          u8500       st-ericsson     u8500               u8500_href                            -                                                                                                                                 -
 Active  arm         armv7          vf610       freescale       vf610twr            vf610twr                              vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg                                                                         Alison Wang <[email protected]>

include/configs/socfpga_common.h new file +2 -0

new file mode 100644
index 0000000..4d90952
@@ -0,0 +1,240 @@
+/*
+ *  Copyright (C) 2012 Altera Corporation <www.altera.com>

include/configs/socfpga_common.h new file +4 -0

+/*
+ * Hardware drivers
+ */
+

include/configs/socfpga_cyclone5.h +1 -1

index 517070c..d5d59d2 100644
@@ -1,242 +1,16 @@
 /*
- *  Copyright (C) 2012 Altera Corporation <www.altera.com>
+ *  Copyright (C) 2014 Pavel Machek <[email protected]>
  *