[U-Boot-Users] Adding multiple MIPS based SoCs?

[U-Boot-Users] Adding multiple MIPS based SoCs?

[Hans Zuidam]

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 at philips.com

[U-Boot-Users] Adding multiple MIPS based SoCs?

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Artificial Intelligence is the study of how to  make  real  computers
act like the ones in movies.

[U-Boot-Users] Adding multiple MIPS based SoCs?

[Ulf Samuelsson]

>> 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 at dof.se, 
since it will be routed to my GSM phone.
My email address is ulf at atmel.com

Best Regards
Ulf Samuelsson                ulf at 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 at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com
Best AVR  link: www.avrfreaks.net

[U-Boot-Users] Adding multiple MIPS based SoCs?

[Wolfgang Denk]

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 at 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Real Programmers always confuse Christmas and Halloween because
OCT 31 == DEC 25 !  - Andrew Rutherford (andrewr at ucs.adelaide.edu.au)

[U-Boot-Users] tools for NIOS/Microblaze/

[Ulf Samuelsson]

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

[U-Boot-Users] Adding multiple MIPS based SoCs?

[Hans Zuidam]

Hi,

wd at 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 at philips.com