[U-Boot-Users] Adding multiple MIPS based SoCs?
Hi,
We are in the process of adding our internal U-Boot changes to the latest public U-Boot. One "problem" we face is that we have multiple SoCs each with a (slightly) different MIPS core variant. Adding them all under cpu/mips and #ifdef-ing start.S does not seem appealing. Our preference is to have a separate cpu directory for each SoC, more or less as is done for the MPCs. Any ideas, suggestions? Thanks in advance.
Regards, Hans -- Hans Zuidam Sen. Systems Engineer, BL DTS ICE, Philips Semiconductors
Building A410, Room 3.40 High Tech Campus 41, 5656 AE Eindhoven, The Netherlands Tel. +31 (0)40 2746579 E-Mail: hans.zuidam@philips.com
Hello,
in message OF51A31EC6.B89D2950-ONC12571D2.004EA12B-C12571D2.004F2D04@philips.com you wrote:
We are in the process of adding our internal U-Boot changes to the latest public U-Boot. One "problem" we face is that we have multiple SoCs each with a (slightly) different MIPS core variant. Adding them all under cpu/mips and #ifdef-ing start.S does not seem appealing. Our preference is to have a separate cpu directory for each SoC, more or less as is done for the MPCs. Any ideas, suggestions? Thanks in advance.
There is no general answer so such a vague question. If there are inded only slight differences, separate directories would probably contain mostly duplicated code, which is unacceptable. Then rather have a few (I really mean *few*) #ifdef's, or call some private init function which can be implemented in a board / SoC specific way.
Best regards,
Wolfgang Denk
We are in the process of adding our internal U-Boot changes to the latest public U-Boot. One "problem" we face is that we have multiple SoCs each with a (slightly) different MIPS core variant. Adding them all under cpu/mips and #ifdef-ing start.S does not seem appealing. Our preference is to have a separate cpu directory for each SoC, more or less as is done for the MPCs. Any ideas, suggestions? Thanks in advance.
There is no general answer so such a vague question. If there are inded only slight differences, separate directories would probably contain mostly duplicated code, which is unacceptable. Then rather have a few (I really mean *few*) #ifdef's, or call some private init function which can be implemented in a board / SoC specific way.
Have been thinking of similar problems:
The README file says that the board directory needs to have a board*.c u-boot.lds flash.c
Since the flash.c is in many cases identical, does it not make more sense to have it in the drivers directory, and then call it something more specific like:
at45dbxxx.c at49bvxxx.c
Then anyone can use these files for their board, instead of duplicating the file.
Best regards,
Wolfgang Denk
Please do not send mails or "reply" to ulfs@dof.se, since it will be routed to my GSM phone. My email address is ulf@atmel.com
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
Technical support when I am not available: AT89 C51 Applications Group: mailto:micro.hotline@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net
In message 00a201c6c5fc$13e4a5a0$104765d5@atmel.com you wrote:
Since the flash.c is in many cases identical, does it not make more sense to have it in the drivers directory, and then call it something more specific like:
You should never duplicate code. If you are aware that you diplicate one forle for another port, you should always use common code. There are many examples for this; for example, type:
-> ls -d board/*/common
in the U-Boot source directory.
Then anyone can use these files for their board, instead of duplicating the file.
You should nevcer duplicated files.
Please do not send mails or "reply" to ulfs@dof.se,
Please do not explicitely set the "From:" and "Return-path:" headers to an address you don't want to see used.
Best regards,
Wolfgang Denk
If you want to run MAKEALL , then you need to have toolchains for a large number of CPUs I did run my patches on other AT91 boards to check for brokenness. crosstool will allow PowerPC, ARM, MIPS; but what about NIOS, Microblaze, Coldfire
Any similar scripts to build toolchains for those?
Best Regards Ulf Samuelsson
Hi,
wd@denx.de wrote on 22-08-2006 16:48:12:
(I really mean *few*) #ifdef's,
It usually starts out with really a few #ifdef's ;-). Among MIPS cores the main differences are in the implementation of the co-processors that manage exceptions, the MMU and the caches. The slightness in difference is more in the area of the relocation code and other common parts. We will go for separate CPU directories for each of the SoCs and factor out the common parts where they exist.
(BTW. what is good form when replying: send the reply to both the sender and the list or only the list?)
Regards, Hans -- Hans Zuidam Sen. Systems Engineer, BL DTS ICE, Philips Semiconductors
Building A410, Room 3.40 High Tech Campus 41, 5656 AE Eindhoven, The Netherlands Tel. +31 (0)40 2746579 E-Mail: hans.zuidam@philips.com
participants (3)
-
Hans Zuidam -
Ulf Samuelsson -
Wolfgang Denk