[U-Boot] [PATCH] FPU POST: fix warnings when building with 2.18 binutils
When compile u-boot with the 2.18 binutils the following
warning messages for each object file in post/lib_ppc/fpu/ is
produced at the linking stage:
post/libpost.a(acc1.o) uses hard float, u-boot uses soft-float
...
This is because of the fact that, in general, the soft-float and
hard-float ABIs are incompatible; the 2.18 binutils do checking
of the Tag_GNU_Power_ABI_FP attribute of the files to be linked, and
produce the worning like above if these are not compatible.
The incompatibility of ABIs is concerned only the float values:
e.g. the soft-float ABI assumes the float argument passing in the
pair of rX registers, and the hard-float ABI assumes passing of
the float argument in the fX register. When we don't pass the float
arguments between the functions compiled with different floatness,
then such an application will work correctly.
This is the case for the FPU POST: u-boot (compiled with soft-float)
doesn't pass to (and doesn't get from) the FPU POST functions any
floats; there are no functions exported from the post/lib_ppc/fpu/
objects which would work with float parameters/returns too. So, we
can reassure the linker not to worry about the difference in ABI
attributes of linking files just by setting the 'soft-float'
attribute for the objects in post/lib_ppc/fpu. And this patch does
this.
Also, to avoid passing both soft- and hard-float options in CFLAGS
when compiling the files from post/lib_ppc/fpu (which is OK, but
looks rather dirty) this patch removes the soft-float string from
CFLAGS in post/lib_ppc/fpu/Makefile.
Signed-off-by: Yuri Tikhonov y...@emcraft.com
---
include/post.h| 13 +
post/lib_ppc/fpu/20001122-1.c |2 ++
post/lib_ppc/fpu/20010114-2.c |2 ++
post/lib_ppc/fpu/20010226-1.c |2 ++
post/lib_ppc/fpu/980619-1.c |2 ++
post/lib_ppc/fpu/Makefile |1 +
post/lib_ppc/fpu/acc1.c |2 ++
post/lib_ppc/fpu/compare-fp-1.c |2 ++
post/lib_ppc/fpu/fpu.c|2 ++
post/lib_ppc/fpu/mul-subnormal-single-1.c |2 ++
10 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/include/post.h b/include/post.h
index 97583b7..fe96312 100644
--- a/include/post.h
+++ b/include/post.h
@@ -80,6 +80,19 @@ extern struct post_test post_list[];
extern unsigned int post_list_size;
extern int post_hotkeys_pressed(void);
+/*
+ * If GCC is configured to use a version of GAS that supports
+ * the .gnu_attribute directive, it will use that directive to
+ * record certain properties of the output code.
+ * This feature is new to GCC 4.3.0.
+ * .gnu_attribute is new to GAS 2.18.
+ */
+#if (__GNUC__ = 4 __GNUC_MINOR__ = 3)
+/* Tag_GNU_Power_ABI_FP/soft-float */
+#define GNU_FPOST_ATTR asm(.gnu_attribute 4, 2);
+#else
+#define GNU_FPOST_ATTR
+#endif /* __GNUC__ */
#endif /* __ASSEMBLY__ */
#define CONFIG_SYS_POST_RTC0x0001
diff --git a/post/lib_ppc/fpu/20001122-1.c b/post/lib_ppc/fpu/20001122-1.c
index a8537fa..bef80c5 100644
--- a/post/lib_ppc/fpu/20001122-1.c
+++ b/post/lib_ppc/fpu/20001122-1.c
@@ -30,6 +30,8 @@
#if CONFIG_POST CONFIG_SYS_POST_FPU
+GNU_FPOST_ATTR
+
int fpu_post_test_math1 (void)
{
volatile double a, *p;
diff --git a/post/lib_ppc/fpu/20010114-2.c b/post/lib_ppc/fpu/20010114-2.c
index 91e3631..ee564e8 100644
--- a/post/lib_ppc/fpu/20010114-2.c
+++ b/post/lib_ppc/fpu/20010114-2.c
@@ -30,6 +30,8 @@
#if CONFIG_POST CONFIG_SYS_POST_FPU
+GNU_FPOST_ATTR
+
static float rintf (float x)
{
volatile float TWO23 = 8388608.0;
diff --git a/post/lib_ppc/fpu/20010226-1.c b/post/lib_ppc/fpu/20010226-1.c
index b00386b..099ca4a 100644
--- a/post/lib_ppc/fpu/20010226-1.c
+++ b/post/lib_ppc/fpu/20010226-1.c
@@ -30,6 +30,8 @@
#if CONFIG_POST CONFIG_SYS_POST_FPU
+GNU_FPOST_ATTR
+
int fpu_post_test_math3 (void)
{
volatile long double dfrom = 1.1;
diff --git a/post/lib_ppc/fpu/980619-1.c b/post/lib_ppc/fpu/980619-1.c
index ceb2b76..46a31ae 100644
--- a/post/lib_ppc/fpu/980619-1.c
+++ b/post/lib_ppc/fpu/980619-1.c
@@ -30,6 +30,8 @@
#if CONFIG_POST CONFIG_SYS_POST_FPU
+GNU_FPOST_ATTR
+
int fpu_post_test_math4 (void)
{
volatile float reale = 1.0f;
diff --git a/post/lib_ppc/fpu/Makefile b/post/lib_ppc/fpu/Makefile
index db43593..a681539 100644
--- a/post/lib_ppc/fpu/Makefile
+++ b/post/lib_ppc/fpu/Makefile
@@ -29,4 +29,5 @@ COBJS-$(CONFIG_HAS_POST) += acc1.o compare-fp-1.o
mul-subnormal-single-1.o
include $(TOPDIR)/post/rules.mk
+CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//)
CFLAGS += -mhard-float -fkeep-inline-functions
diff --git a/post/lib_ppc/fpu/acc1.c b/post/lib_ppc/fpu/acc1.c
index 8a65193..9fca9b3 100644
--- a/post/lib_ppc/fpu/acc1.c
+++ b/post/lib_ppc/fpu/acc1.c
@@ -30,6 +30,8 @@
#if CONFIG_POST CONFIG_SYS_POST_FPU
+GNU_FPOST_ATTR
+
static double func (const double *array)
{
double d = *array
[U-Boot] [PATCH] katmai: change default config
Hello, This patch enables support for EXT2, and increases the CONFIG_SYS_BOOTMAPSZ size for the default configuration of the katmai boards to use them as the RAID-reference AMCC setups. EXT2 enabling allows one to boot kernels from the EXT2 formatted Compact Flash cards. CONFIG_SYS_BOOTMAPSZ increasing allows one to boot the Linux kernels, which use PAGE_SIZE of 256KB. Otherwise, the memory area with DTB file (which is placed at the end of the bootmap area) will turn out to be overlapped with the BSS segment of the 256KB kernel, and zeroed in early_init() of Linux. Actually, increasing of the bootmap size could be done via setting of the bootm_size U-Boot variable, but it looks like the current U-Boot implementation have some bootm_size- related functionality lost. In many places through the U-Boot code the CONFIG_SYS_BOOTMAPSZ definition is used directly (instead of trying to read the corresponding value from the environment). The same is truth for the boot_jump_linux() function in lib_ppc/bootm.c, where U-Boot transfers control to Linux passing the CONFIG_SYS_BOOTMAPSZ (not bootm_size) value to the booting kernel. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Ilya Yanok [EMAIL PROTECTED] --- include/configs/katmai.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/include/configs/katmai.h b/include/configs/katmai.h index 58694cc..74e0ecd 100644 --- a/include/configs/katmai.h +++ b/include/configs/katmai.h @@ -53,6 +53,13 @@ #define CONFIG_HOSTNAMEkatmai #include amcc-common.h +/* + * For booting 256K-paged Linux we should have 16MB of memory + * for Linux initial memory map + */ +#undef CONFIG_SYS_BOOTMAPSZ +#define CONFIG_SYS_BOOTMAPSZ (16 20) + #define CONFIG_BOARD_EARLY_INIT_F 1/* Call board_pre_init */ #undef CONFIG_SHOW_BOOT_PROGRESS @@ -189,6 +196,7 @@ /* * Commands additional to the ones defined in amcc-common.h */ +#define CONFIG_CMD_EXT2 #define CONFIG_CMD_DATE #define CONFIG_CMD_PCI #define CONFIG_CMD_SDRAM -- 1.5.6.1 -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 440spe MQ initialization
Set the MQ Read Passing MCIF Cycle limits to the recommended by AMCC values. This fixes the occasional 440SPe hard locking issues when the 440SPe's dedicated DMA engines are used (e.g. by the h/w accelerated RAID driver). Previously the appropriate initialization had been made in Linux, by the ppc440spe ADMA driver, which is wrong because modifying the MQ configuration registers after normal operation has begun is not supported and could have unpredictable results. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] --- cpu/ppc4xx/44x_spd_ddr2.c | 10 ++ include/asm-ppc/ppc4xx-sdram.h |5 + 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/cpu/ppc4xx/44x_spd_ddr2.c b/cpu/ppc4xx/44x_spd_ddr2.c index f1d7684..995d5fe 100644 --- a/cpu/ppc4xx/44x_spd_ddr2.c +++ b/cpu/ppc4xx/44x_spd_ddr2.c @@ -2261,10 +2261,12 @@ static void program_memory_queue(unsigned long *dimm_populated, /* * Set optimal value for Memory Queue HB/LL Configuration registers */ - mtdcr(SDRAM_CONF1HB, mfdcr(SDRAM_CONF1HB) | SDRAM_CONF1HB_AAFR | - SDRAM_CONF1HB_RPEN | SDRAM_CONF1HB_RFTE); - mtdcr(SDRAM_CONF1LL, mfdcr(SDRAM_CONF1LL) | SDRAM_CONF1LL_AAFR | - SDRAM_CONF1LL_RPEN | SDRAM_CONF1LL_RFTE); + mtdcr(SDRAM_CONF1HB, (mfdcr(SDRAM_CONF1HB) ~SDRAM_CONF1HB_MASK) | + SDRAM_CONF1HB_AAFR | SDRAM_CONF1HB_RPEN | SDRAM_CONF1HB_RFTE | + SDRAM_CONF1HB_RPLM | SDRAM_CONF1HB_WRCL); + mtdcr(SDRAM_CONF1LL, (mfdcr(SDRAM_CONF1LL) ~SDRAM_CONF1LL_MASK) | + SDRAM_CONF1LL_AAFR | SDRAM_CONF1LL_RPEN | SDRAM_CONF1LL_RFTE | + SDRAM_CONF1LL_RPLM); mtdcr(SDRAM_CONFPATHB, mfdcr(SDRAM_CONFPATHB) | SDRAM_CONFPATHB_TPEN); #endif } diff --git a/include/asm-ppc/ppc4xx-sdram.h b/include/asm-ppc/ppc4xx-sdram.h index 8efa557..98faced 100644 --- a/include/asm-ppc/ppc4xx-sdram.h +++ b/include/asm-ppc/ppc4xx-sdram.h @@ -272,8 +272,11 @@ #define SDRAM_CONF1HB_PRPD 0x0008 /* PLB Read pipeline Disable - Bit 12 */ #define SDRAM_CONF1HB_PWPD 0x0004 /* PLB Write pipeline Disable - Bit 13 */ #define SDRAM_CONF1HB_PRW 0x0002 /* PLB Read Wait - Bit 14 */ +#define SDRAM_CONF1HB_RPLM 0x1000 /* Read Passing Limit 1 - Bits 16..19 */ #define SDRAM_CONF1HB_RPEN 0x0800 /* Read Passing Enable - Bit 20 */ #define SDRAM_CONF1HB_RFTE 0x0400 /* Read Flow Through Enable - Bit 21 */ +#define SDRAM_CONF1HB_WRCL 0x0080 /* MCIF Cycle Limit 1 - Bits 22..24 */ +#define SDRAM_CONF1HB_MASK 0xF380 /* RPLM WRCL mask */ #define SDRAM_ERRSTATHB(SDRAMQ_DCR_BASE+0x7) /* error status HB */ #define SDRAM_ERRADDUHB(SDRAMQ_DCR_BASE+0x8) /* error address upper 32 HB */ @@ -284,8 +287,10 @@ #define SDRAM_CONF1LL_PRPD 0x0008 /* PLB Read pipeline Disable - Bit 12 */ #define SDRAM_CONF1LL_PWPD 0x0004 /* PLB Write pipeline Disable - Bit 13 */ #define SDRAM_CONF1LL_PRW 0x0002 /* PLB Read Wait - Bit 14 */ +#define SDRAM_CONF1LL_RPLM 0x1000 /* Read Passing Limit 1 - Bits 16..19 */ #define SDRAM_CONF1LL_RPEN 0x0800 /* Read Passing Enable - Bit 20 */ #define SDRAM_CONF1LL_RFTE 0x0400 /* Read Flow Through Enable - Bit 21 */ +#define SDRAM_CONF1LL_MASK 0xF000 /* RPLM mask */ #define SDRAM_ERRSTATLL(SDRAMQ_DCR_BASE+0xC) /* error status LL */ #define SDRAM_ERRADDULL(SDRAMQ_DCR_BASE+0xD) /* error address upper 32 LL */ -- 1.5.6.1 Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 440spe MQ initialization
Hello, BTW, when I said recommended by AMCC in the patch description I referred to the following information forwarded to me by Wolfgang Denk on Tue Mar 18 2008: --- Dear Yuri, here is some additional (and hopefully helpful) information from AMCC regarding the observed hangs on the katmai board: If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF00 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF00 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering Best regards, Wolfgang Denk --- On Tuesday, September 23, 2008 you wrote: Hi Yuri, On Tuesday 23 September 2008, Yuri Tikhonov wrote: Set the MQ Read Passing MCIF Cycle limits to the recommended by AMCC values. This fixes the occasional 440SPe hard locking issues when the 440SPe's dedicated DMA engines are used (e.g. by the h/w accelerated RAID driver). Previously the appropriate initialization had been made in Linux, by the ppc440spe ADMA driver, which is wrong because modifying the MQ configuration registers after normal operation has begun is not supported and could have unpredictable results. AMCC just recently updated the 440SP(e) MQ initialization with this patch: commit 079589bcfb24ba11068460276a3cc9549ab5346f Author: Prodyut Hazarika [EMAIL PROTECTED] Date: Wed Aug 20 09:38:51 2008 -0700 ppc4xx: Optimize PLB4 Arbiter and Memory Queue settings for PPC440SP/SPe, PPC405EX and PPC460EX/GT/SX - Read pipeline depth set to 4 for PPC440SP/SPE, PPC405EX, PPC460EX/GT/SX processors - Moved PLB4 Arbiter register definitions to ppc4xx.h since it is shared across processors (405 and 440/460) - Optimize Memory Queue settings for PPC440SP/SPE and PPC460EX/GT/SX processors - Add register bit definitions for Memory Queue Configuration registers Signed-off-by: Prodyut Hazarika [EMAIL PROTECTED] Signed-off-by: Stefan Roese [EMAIL PROTECTED] I have a bad feeling changing this optimized settings without AMCC's specific ACK. Prodyut, are you ok with Yuri's change? Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 440spe MQ initialization
Hello Prodyut, On Tuesday, September 23, 2008 you wrote: Hi Stefan/Yuri, I looked at the changes. I had already submitted the changes in an earlier patch. This code to set the PLB4 arbiter depth was moved to cpu_init_f function in cpu/ppc4xx/cpu_init.c since it is common across many processor families. Please don't do the same thing again in the program_memory_queue function. Well, actually my patch doesn't have a deal with the PLB configuring, but with MQ only. So, it's OK here. But then another question arises: in Linux, in ppc440spe_configure_raid_devices(), beside the other things we do the following: /* Configure PLB as follows: * PLB: 0xDF00. This means * - Priority level 00 fair priority, * - Priority level 01 fair priority, * - Priority level 11 fair priority, * - High Bus Utilization enabled, * - 4 Deep read pipe, * - 2 Deep write pipe. */ mask = (1 PLB_ACR_PPM0) | (1 PLB_ACR_PPM1) | (1 PLB_ACR_PPM3) | (1 PLB_ACR_HBU) | ((3 PLB_ACR_RDP_MSK) PLB_ACR_RDP) | (1 PLB_ACR_WRP); mtdcr(DCRN_PLB0_ACR, mask); mtdcr(DCRN_PLB1_ACR, mask); Is it OK, or should we remove these strings from the Linux driver, assuming U-Boot has already done this ? Thanks in advance, Yuri From: Stefan Roese [mailto:[EMAIL PROTECTED] Sent: Tue 9/23/2008 2:43 AM To: Yuri Tikhonov Cc: u-boot@lists.denx.de; Prodyut Hazarika; Olga Buchonina Subject: Re: [U-Boot] [PATCH] 440spe MQ initialization On Tuesday 23 September 2008, Yuri Tikhonov wrote: BTW, when I said recommended by AMCC in the patch description I referred to the following information forwarded to me by Wolfgang Denk on Tue Mar 18 2008: --- Dear Yuri, here is some additional (and hopefully helpful) information from AMCC regarding the observed hangs on the katmai board: If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF00 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF00 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering Understood. I just would like to see an ACK from AMCC on this since they just updated this MQ init code. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 440spe MQ initialization
Hi Prodyut, On Tuesday, September 23, 2008 you wrote: Hi Yuri, Is it OK, or should we remove these strings from the Linux driver, assuming U-Boot has already done this ? Please go ahead and remove these from the linux driver. Thanks for confirmation, will do. And I think this driver has not been submitted to the powerpc tree, since I still don't see it in Josh's or Linus's tree. Yep, for now it's present in the linux-2.6-denx tree only. We are about to post this to MLs along with our RAID-6 related changes soon. From: Stefan Roese [mailto:[EMAIL PROTECTED] Sent: Tue 9/23/2008 2:43 AM To: Yuri Tikhonov Cc: u-boot@lists.denx.de; Prodyut Hazarika; Olga Buchonina Subject: Re: [U-Boot] [PATCH] 440spe MQ initialization On Tuesday 23 September 2008, Yuri Tikhonov wrote: BTW, when I said recommended by AMCC in the patch description I referred to the following information forwarded to me by Wolfgang Denk on Tue Mar 18 2008: --- Dear Yuri, here is some additional (and hopefully helpful) information from AMCC regarding the observed hangs on the katmai board: If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF00 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF00 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering Understood. I just would like to see an ACK from AMCC on this since they just updated this MQ init code. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
