From: Ulf Samuelsson <ulf@atmel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] arm SoC code in U-Boot.
Date: Mon, 5 Mar 2007 12:38:22 +0100 [thread overview]
Message-ID: <04a901c75f1a$d23c63f0$d389fea9@atmel.com> (raw)
In-Reply-To: 45E7F65C.9090900@aotek.es
----- 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
next prev parent reply other threads:[~2007-03-05 11:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-02 10:03 [U-Boot-Users] arm SoC code in U-Boot Txema Lopez
2007-03-05 11:38 ` Ulf Samuelsson [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-03-06 17:02 Peter Pearse
2007-03-06 21:36 ` Wolfgang Denk
2007-03-06 21:55 ` Ulf Samuelsson
2007-03-06 22:32 ` Wolfgang Denk
2007-03-06 22:45 ` Ulf Samuelsson
2007-03-07 6:30 ` Stefan Roese
2007-03-07 12:37 ` Haavard Skinnemoen
2007-03-07 14:27 ` Ben Warren
2007-03-07 14:39 ` Wolfgang Denk
2007-03-08 8:17 TXEMA LOPEZ
2007-03-08 8:40 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='04a901c75f1a$d23c63f0$d389fea9@atmel.com' \
--to=ulf@atmel.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox