[U-Boot-Users] arm SoC code in U-Boot.

[U-Boot-Users] arm SoC code in U-Boot.

[Peter Pearse]

Hi
	I see from
http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=02XPgQ82172
973 that 
there are IMX SOCs with three different ARM cores (920, 926, 1136).

Hopefully, there would be some commonality in the u-boot imx code - so
repeating it under the individual cpus seems wasteful.

Arguably freescale could produce a SOC with someone else's core 

(although I think that would be a silly idea of course ;-> )


I could live with cpu/freescale/imx. Presumably it would be built in
via the SOC value?

Regards

Peter

-- 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

[U-Boot-Users] arm SoC code in U-Boot.

[Wolfgang Denk]

In message <89A528FE6DB0FA44877BB2F05B84671805650CA4@ZIPPY.Emea.Arm.com> you wrote:
>
> I could live with cpu/freescale/imx. Presumably it would be built in
> via the SOC value?

Do we really need the "freescale" subdirectory here? Maybe
cpu/arm_imx would be a shorter and more descriptive name?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
People seldom know what they want until you give them what  they  ask
for.

[U-Boot-Users] arm SoC code in U-Boot.

[Ulf Samuelsson]

link: www.avrfreaks.net
----- Original Message ----- 
From: "Wolfgang Denk" <wd@denx.de>
To: "Peter Pearse" <Peter.Pearse@arm.com>
Cc: <u-boot-users@lists.sourceforge.net>; "Ulf Samuelsson" <ulf@atmel.com>; 
"Txema Lopez" <tlopez@aotek.es>; "Grant Likely" <grant.likely@secretlab.ca>
Sent: Tuesday, March 06, 2007 10:36 PM
Subject: Re: [U-Boot-Users] arm SoC code in U-Boot.


> In message <89A528FE6DB0FA44877BB2F05B84671805650CA4@ZIPPY.Emea.Arm.com> 
> you wrote:
>>
>> I could live with cpu/freescale/imx. Presumably it would be built in
>> via the SOC value?
>
> Do we really need the "freescale" subdirectory here? Maybe
> cpu/arm_imx would be a shorter and more descriptive name?
>
> Best regards,
>
> Wolfgang Denk
>


I think it is a matter of taste.
You actually do not need to have any subdirectories in U-boot at all.
Some people prefer using a directory structure to hide information
which is of little interest to them

There seems to be shared code for PowerPCs and NIOS(2).
Do we want to create new subdirectories for every share, cluttering up 
"cpu"?

I think the likelyhood for shared code between different Freescale
PPC is higher than shared code between IBM and Freescale PPC.
Therefore a "freescale" directory could also contains shared PPC code.

Some people would like to have consistency
making it easy to find where things are located.

If you look at what is driving duplication, then you find
that the peripherals are either developed inside a semiconductor
company, or they are licensed from an IP provider.

It makes a lot of sense therefore to dedicate directories
to the providers of IP:
ARM is a provider, but so are also Freescale, Atmel and others.


Best Regards
Ulf Samuelsson

[U-Boot-Users] arm SoC code in U-Boot.

[Wolfgang Denk]

In message <006701c7603a$95ed3930$01c4af0a@Glamdring> you wrote:
>
> ----- Original Message ----- 

Please don't top-post / full quote. Thanks.

> > Do we really need the "freescale" subdirectory here? Maybe
> > cpu/arm_imx would be a shorter and more descriptive name?
...
> I think it is a matter of taste.

Agreed.

> Some people would like to have consistency
> making it easy to find where things are located.

To me making it easy to find where things are located includes not to
add unnecessary directory levels.

When adding "cpu/freescale/" I see no clear line what  should  go  in
there  and  what  not.  Whould  we  then  move  all  the  cpu/mpc???/
directories into cpu/freescale/  ?  And  then  probably  create  (for
consistency)  a  "cpu/amcc/"  directory and mode cpu/ppc4xx into that
one? What do we get in addition to another directory level? IMO  that
would not improve anything, and you still don't see where shared code
is located.

> If you look at what is driving duplication, then you find
> that the peripherals are either developed inside a semiconductor
> company, or they are licensed from an IP provider.
> 
> It makes a lot of sense therefore to dedicate directories
> to the providers of IP:
> ARM is a provider, but so are also Freescale, Atmel and others.

Well, where did license Freescale the IMX core from?  I  don't  think
that  we  should  focus on vendor names here, but instead on content.
And the content is "ARM IMX"  related  code.  Assuming  that  is  CPU
specific  enough  to  go  under "cpu/", I feel we should either add a
"cpu/imx" directory or - a little more descriptive  -  "cpu/arm_imx/"
as suggested above. Even "cpu/arm/imx/" seems more natural to me than
"cpu/freescale/imx/".

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You are an excellent tactician, Captain. You let your second in  com-
mand attack while you sit and watch for weakness.
	-- Khan Noonian Singh, "Space Seed", stardate 3141.9

[U-Boot-Users] arm SoC code in U-Boot.

[Ulf Samuelsson]

>> > Do we really need the "freescale" subdirectory here? Maybe
>> > cpu/arm_imx would be a shorter and more descriptive name?
> ...
>> I think it is a matter of taste.
>
> Agreed.
>
>> Some people would like to have consistency
>> making it easy to find where things are located.
>
> To me making it easy to find where things are located includes not to
> add unnecessary directory levels.
>
> When adding "cpu/freescale/" I see no clear line what  should  go  in
> there  and  what  not.  Whould  we  then  move  all  the  cpu/mpc???/
> directories into cpu/freescale/  ?  And  then  probably  create  (for
> consistency)  a  "cpu/amcc/"  directory and mode cpu/ppc4xx into that
> one? What do we get in addition to another directory level? IMO  that
> would not improve anything, and you still don't see where shared code
> is located.

I think you can still keep the cpu/ppc4xx directory but if you
find that cpu/ppcYYY has shared code with the cpu/ppc4xx
and you would like to have a common driver, then
you put it in "cpu/amcc/ppc.

For freescale you would put shared code in
cpu/freescale/imx and cpu/freescale/ppc
and maybe cpu/freescale/coldfire

>
>> If you look at what is driving duplication, then you find
>> that the peripherals are either developed inside a semiconductor
>> company, or they are licensed from an IP provider.
>>
>> It makes a lot of sense therefore to dedicate directories
>> to the providers of IP:
>> ARM is a provider, but so are also Freescale, Atmel and others.
>
> Well, where did license Freescale the IMX core from?  I  don't  think
> that  we  should  focus on vendor names here, but instead on content.
> And the content is "ARM IMX"  related  code.  Assuming  that  is  CPU
> specific  enough  to  go  under "cpu/", I feel we should either add a
> "cpu/imx" directory or - a little more descriptive  -  "cpu/arm_imx/"
> as suggested above. Even "cpu/arm/imx/" seems more natural to me than
> "cpu/freescale/imx/".
>

I might be wrong, but  think the issue is that
Freescale has some common peripherals which are used
both on ARM926EJS and ARM920T chips.

If the peripherals are licensed from ARM, then I think that the peripheral
might be in use in other ARM chipa I.E. non-imx chips as well and "cpu/arm" 
would
be OK, but not "cpu/arm/imx"
.
If the peripherals are developed by Freescale, then if they
happen to use the peripheral on a non-ARM chip then
the cpu/arm/imx is no good and cpu/arm_imx is also no good.
"cpu/freescale" is then much better for generic stuff
and "cpu/freescale/imx" for things shared only among imx chips.
.





cpu/arm could
be a directory, but then it is


> Best regards,
>
> Wolfgang Denk
>


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] SDRAM cache inhibit

[David Clark]

Hopefully this is an easy one.  At first glance this looks like the FAQ
question but there is a difference.

First the background:

I have what I believe is an SDRAM issue.  Linux intermittently locks up
upon boot and I have verified that when this happens there is bad or
invalid instructions at certain memory locations after U-boot
uncompresses the image and loads it into RAM.  I have a few boards that
have never exhibited this problem and some boards that intermittently
exhibit this problem.  I have written a test that uncompress and loads
the image into SDRAM then, rather that booting it, compares the
uncompressed image to a copy of the uncompressed image residing in a
higher area of flash.  This way I can run it in a loop and see the
intermittent failures.

The real reason I'm writing here is because to verify that it is an
SDRAM issue I wanted to inhibit caching of the SDRAM figuring that this
would allow thing to work without all the SDRAM bursting.  When I do
this however I get a crash at the "U-boot relocating to..." line.  I'm
using an MPC8245 and have tried the following combination of iBAT and
dBAT settings for the SDRAM with the following results:

- iBAT = memory coherence, dBAT = memory coherence, U-boot works
- iBAT = cache inhibit, dBAT = memory coherence, U-boot works
- iBAT = memory coherence, dBAT = cache inhibit, U-boot fails
- iBAT = cache inhibit, dBAT = cache inhibit, U-boot fails

In summary U-boot works with caching but it fails whenever the dBAT is
set to cache inhibit for the SDRAM.  Is this expected operation or is it
further indication of an SDRAM problem?

David Clark
Senior Software Engineer
C&H Technologies, Inc
Web: http:\\www.chtech.com
Phone: 512-733-2621
Fax: 512-733-2629
Email: dlclark at chtech.com
 

[U-Boot-Users] SDRAM cache inhibit

[Wolfgang Denk]

In message <008001c7604a$661c0ff0$0f01a8c0@longhorn> you wrote:
>
...
> using an MPC8245 and have tried the following combination of iBAT and
...
> In summary U-boot works with caching but it fails whenever the dBAT is
> set to cache inhibit for the SDRAM.  Is this expected operation or is it
> further indication of an SDRAM problem?

See the README. "Data cache ... cannot be disabled ..."

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"You know, after a woman's raised a family and so on,  she  wants  to
start living her own life."   "Whose life she's _been_ living, then?"
                                  - Terry Pratchett, _Witches Abroad_

[U-Boot-Users] SDRAM cache inhibit

[David Clark]

> See the README. "Data cache ... cannot be disabled ..."

To be thorough, I am not disabling cache; I am instead marking the SDRAM
as cache inhibited via the BAT registers.  

It was my understanding (apparently incorrect), from the README that the
reason "Data cache ... cannot be disabled ..." was due to the (mis-) use
cache for initialization purposes.  In my case my data cache is still
enabled and my CFG_INIT_RAM_ADDR block is still cacheable.  

Is my understanding flawed?

David Clark
Senior Software Engineer
C&H Technologies, Inc
Web: http:\\www.chtech.com
Phone: 512-733-2621
Fax: 512-733-2629
Email: dlclark at chtech.com
 

-----Original Message-----
From: wd@denx.de [mailto:wd at denx.de] 
Sent: Tuesday, March 06, 2007 6:06 PM
To: David Clark
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] SDRAM cache inhibit 

In message <008001c7604a$661c0ff0$0f01a8c0@longhorn> you wrote:
>
...
> using an MPC8245 and have tried the following combination of iBAT and
...
> In summary U-boot works with caching but it fails whenever the dBAT is
> set to cache inhibit for the SDRAM.  Is this expected operation or is
it
> further indication of an SDRAM problem?

See the README. "Data cache ... cannot be disabled ..."

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"You know, after a woman's raised a family and so on,  she  wants  to
start living her own life."   "Whose life she's _been_ living, then?"
                                  - Terry Pratchett, _Witches Abroad_

[U-Boot-Users] arm SoC code in U-Boot.

[Stefan Roese]

On Tuesday 06 March 2007 23:45, Ulf Samuelsson wrote:
> > When adding "cpu/freescale/" I see no clear line what  should  go  in
> > there  and  what  not.  Whould  we  then  move  all  the  cpu/mpc???/
> > directories into cpu/freescale/  ?  And  then  probably  create  (for
> > consistency)  a  "cpu/amcc/"  directory and mode cpu/ppc4xx into that
> > one? What do we get in addition to another directory level? IMO  that
> > would not improve anything, and you still don't see where shared code
> > is located.
>
> I think you can still keep the cpu/ppc4xx directory but if you
> find that cpu/ppcYYY has shared code with the cpu/ppc4xx
> and you would like to have a common driver, then
> you put it in "cpu/amcc/ppc.
>
> For freescale you would put shared code in
> cpu/freescale/imx and cpu/freescale/ppc
> and maybe cpu/freescale/coldfire

I still think that this code we are talking about here, is most likely some 
driver code for some ethernet controller, or a I2C controller etc. I would 
like to "collect" this sort of driver code, even if it's SoC driver code, 
under the "drivers" directory. This is already done for some drivers but it's 
not done consistently. We already have:

drivers/qe/*
drivers/netarm_eth.*
drivers/omap1510_i2c.*
...

Why not try to match this a little more to the Linux directory structure:

drivers/net/netarm_eth.*
drivers/net/qe/*
drivers/i2c/omap1510_i2c.*
...

From my understanding the drivers mentioned above will fit in here much better 
than in some cpu directories. Just my 0.02$.

BTW: I know it's always a problem to "move" code in a version control system 
because of the revision history.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
=====================================================================

[U-Boot-Users] arm SoC code in U-Boot.

[Haavard Skinnemoen]

On 3/7/07, Stefan Roese <sr@denx.de> wrote:

> Why not try to match this a little more to the Linux directory structure:
>
> drivers/net/netarm_eth.*
> drivers/net/qe/*
> drivers/i2c/omap1510_i2c.*
> ...

I think this is a great idea. Grouping drivers together by function
makes them much easier to find, and it's also easier to find examples
when you're writing a new driver. With the current layout, you have to
grep through the drivers, cpu and board hierarchies to find existing
drivers similar to the one you're trying to write.

> >From my understanding the drivers mentioned above will fit in here much better
> than in some cpu directories. Just my 0.02$.
>
> BTW: I know it's always a problem to "move" code in a version control system
> because of the revision history.

git makes it much less of a problem than many other version control systems.

Haavard

[U-Boot-Users] arm SoC code in U-Boot.

[Ben Warren]

On Wed, 2007-03-07 at 13:37 +0100, Haavard Skinnemoen wrote:
> On 3/7/07, Stefan Roese <sr@denx.de> wrote:
> 
> > Why not try to match this a little more to the Linux directory structure:
> >
> > drivers/net/netarm_eth.*
> > drivers/net/qe/*
> > drivers/i2c/omap1510_i2c.*
> > ...
> 
> I think this is a great idea. Grouping drivers together by function
> makes them much easier to find, and it's also easier to find examples
> when you're writing a new driver. With the current layout, you have to
> grep through the drivers, cpu and board hierarchies to find existing
> drivers similar to the one you're trying to write.

Stellar idea.  The more logically drivers are grouped, the easier it
will to transition to a menuconfig-based system, which would be pretty
cool, don't you think?

Ben

[U-Boot-Users] arm SoC code in U-Boot.

[Wolfgang Denk]

In message <1defaf580703070437x2d36edd8q52bc86a41d7df2f2@mail.gmail.com> you wrote:
> On 3/7/07, Stefan Roese <sr@denx.de> wrote:
> 
> > Why not try to match this a little more to the Linux directory structure:
> >
> > drivers/net/netarm_eth.*
> > drivers/net/qe/*
> > drivers/i2c/omap1510_i2c.*
> > ...
> 
> I think this is a great idea. Grouping drivers together by function
> makes them much easier to find, and it's also easier to find examples
> when you're writing a new driver. With the current layout, you have to
> grep through the drivers, cpu and board hierarchies to find existing
> drivers similar to the one you're trying to write.
> 

Seems we have an agreement. Let's do it this way, then. Thanks to all
of you.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Language shapes the way we think, and determines what we  can  think
about."                                                 - B. L. Whorf

[U-Boot-Users] arm SoC code in U-Boot.

[TXEMA LOPEZ]

Hi,
I'm afraid I'm quite a bit missing in this discussion. At last, where must I put the imx21 related code? In drivers/imx ? Or will the U-Boot structure be changed (the Soc related code will be spread over drivers/..)?. Must I wait? Must I do something about it?.

Best regards,  

 -----Mensaje original-----
De: 	wd at denx.de [mailto:wd at denx.de] 
Enviado el:	mi?rcoles, 07 de marzo de 2007 15:39
Para:	Haavard Skinnemoen
CC:	Stefan Roese; u-boot-users at lists.sourceforge.net; Ulf Samuelsson; Grant Likely; TXEMA LOPEZ; Peter Pearse
Asunto:	Re: [U-Boot-Users] arm SoC code in U-Boot. 

In message <1defaf580703070437x2d36edd8q52bc86a41d7df2f2@mail.gmail.com> you wrote:
> On 3/7/07, Stefan Roese <sr@denx.de> wrote:
> 
> > Why not try to match this a little more to the Linux directory structure:
> >
> > drivers/net/netarm_eth.*
> > drivers/net/qe/*
> > drivers/i2c/omap1510_i2c.*
> > ...
> 
> I think this is a great idea. Grouping drivers together by function
> makes them much easier to find, and it's also easier to find examples
> when you're writing a new driver. With the current layout, you have to
> grep through the drivers, cpu and board hierarchies to find existing
> drivers similar to the one you're trying to write.
> 

Seems we have an agreement. Let's do it this way, then. Thanks to all
of you.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Language shapes the way we think, and determines what we  can  think
about."                                                 - B. L. Whorf

[U-Boot-Users] arm SoC code in U-Boot.

[Wolfgang Denk]

In message <918EB199DDDFFA42BEA2EB3A1C6021F301646DC3@CORREO> you wrote:
>
> I'm afraid I'm quite a bit missing in this discussion. At last, where
> must I put the imx21 related code? In drivers/imx ? Or will the U-Boot
> structure be changed (the Soc related code will be spread over
> drivers/..)?. Must I wait? Must I do something about it?.

We agreed to have a directory structure like this:

> > > drivers/net/netarm_eth.*
> > > drivers/net/qe/*
> > > drivers/i2c/omap1510_i2c.*

Thinking about this again, there is still unneeded redundancy in the
names, and it would be better to have simple names like that:

	drivers/net/arm*
	drivers/net/qe/*
	drivers/i2c/omap1510.*

So if you have a IMX serial driver that should go to 
	drivers/serial/imx.c
and an ethernet driver to
	drivers/net/imx.c
and your I2C driver to
	drivers/i2c/imx.c

As a minimum, you should start this new directory structure  and  use
it  for  the  IMX  related  code (and leave the cleanup of the other,
already existing code in the  drivers/  directory  to  others).  Even
better,  you  would  include this restructuring of the existing code,
too.

[And ideally, you would clean up all the U-Boot code, merge all  open
patches  and  fix  all  the  remaining  bugs as well. But I guess I'm
asking for too much :-) ]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I really hate this damned machine     It never does quite what I want
I wish that they would sell it.              But only what I tell it.

[U-Boot-Users] arm SoC code in U-Boot.

[Txema Lopez]

Hi all,

I'm working in a port for the csb535fs board. I sent a patch to U-Boot 
that includes a new directory (imx21) for the i.MX21 SoC related code 
following the actual policy of U-Boot. Grant Likely thinks (and now I'm 
agree) this code is very similar to imx code and must be put in the same 
directory. But, the SoC related code in U-Boot is located on the 
cpu/arm**** directories, so it's depends on the arm core. My idea is to 
put all this SoC related code in a specific directory (cpu/arm_soc).
This would be the patch for the makefile.

--- Makefile    2007-02-27 09:59:17.000000000 +0100
+++ NewMakefile    2007-03-02 09:19:33.000000000 +0100
@@ -191,8 +191,12 @@ LIBS  = lib_generic/libgeneric.a
 LIBS += board/$(BOARDDIR)/lib$(BOARD).a
 LIBS += cpu/$(CPU)/lib$(CPU).a
 ifdef SOC
+ifeq ($(ARCH),arm)
+LIBS += cpu/arm_soc/$(SOC)/lib$(SOC).a
+else
 LIBS += cpu/$(CPU)/$(SOC)/lib$(SOC).a
 endif
+endif
 LIBS += lib_$(ARCH)/lib$(ARCH).a
 LIBS += fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a 
fs/jffs2/libjffs2.a \
     fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a

So, these directories
    at91rm9200
    imx
    ks8695
    omap
    s3c240x0
    versatile
Must be moved from cpu/arm**** directories to cpu/arm_soc directory.

This change could be a quite intrusive and would affect quite a few 
boards, so I need some feedback from the list.

Wolfgang proposed a particular solution for the imx related code putting 
it in a new directory (cpu/arm/imx_common). For me is OK too. I don't 
know who has the last say in these questions but I would like to know 
what will be the solution to not work in vain.


Best regards,



  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tlopez.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070302/3aa6a6e8/attachment.vcf 

[U-Boot-Users] arm SoC code in U-Boot.

[Ulf Samuelsson]

----- Original Message ----- 
From: "Txema Lopez" <tlopez@aotek.es>
To: <u-boot-users@lists.sourceforge.net>
Sent: Friday, March 02, 2007 11:03 AM
Subject: [U-Boot-Users] arm SoC code in U-Boot.


> Hi all,
> 
> I'm working in a port for the csb535fs board. I sent a patch to U-Boot 
> that includes a new directory (imx21) for the i.MX21 SoC related code 
> following the actual policy of U-Boot. Grant Likely thinks (and now I'm 
> agree) this code is very similar to imx code and must be put in the same 
> directory. But, the SoC related code in U-Boot is located on the 
> cpu/arm**** directories, so it's depends on the arm core. My idea is to 
> put all this SoC related code in a specific directory (cpu/arm_soc).
> This would be the patch for the makefile.
> 
> --- Makefile    2007-02-27 09:59:17.000000000 +0100
> +++ NewMakefile    2007-03-02 09:19:33.000000000 +0100
> @@ -191,8 +191,12 @@ LIBS  = lib_generic/libgeneric.a
> LIBS += board/$(BOARDDIR)/lib$(BOARD).a
> LIBS += cpu/$(CPU)/lib$(CPU).a
> ifdef SOC
> +ifeq ($(ARCH),arm)
> +LIBS += cpu/arm_soc/$(SOC)/lib$(SOC).a
> +else
> LIBS += cpu/$(CPU)/$(SOC)/lib$(SOC).a
> endif
> +endif
> LIBS += lib_$(ARCH)/lib$(ARCH).a
> LIBS += fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a 
> fs/jffs2/libjffs2.a \
>     fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a
> 
> So, these directories
>    at91rm9200
>    imx
>    ks8695
>    omap
>    s3c240x0
>    versatile
> Must be moved from cpu/arm**** directories to cpu/arm_soc directory.
> 
> This change could be a quite intrusive and would affect quite a few 
> boards, so I need some feedback from the list.
> 
> Wolfgang proposed a particular solution for the imx related code putting 
> it in a new directory (cpu/arm/imx_common). For me is OK too. I don't 
> know who has the last say in these questions but I would like to know 
> what will be the solution to not work in vain.
> 
> 


It won't fix the problem when you have chips with different CPU core
architectures sharing the same peripherals
I.E: ARM926 and AVR32

It is probably better to have directories for IP-vendors.

I.E. cpu/freescale/imx

This have already been proposed by Wolfgang.

Best Regards
Ulf Samuelsson