Skip to contentSkip to conversation

at91sam9263_nandflash build issues

U-Boot Marek Vasut 4 participants 7 messages Feb 2, 2011

Subsystems (2)
SPI Arm/Microchip (AT91) SoC support
lore
Share & tools
lore

Marek Vasut

author
#0 lore raw

The problem is clear from this IRC log, where "vickylinuxer" described his grief (so I included the log, the board really doesn't build). I also did a quick and dirty patch (follows the log, it might give you an idea where it breaks, but it's a mess -- not all is relevant and it probably breaks it even more).

Cheers

//-------- LOG ---------

05:01 < vickylinuxer> guys i am making u-boot for at91sam9263 with ubifs support...which u-boot version i can prefer...
05:02 < vickylinuxer> because u-boot-12-2010 gave so many compilation problems...
05:06 < Marex> vickylinuxer: look ... what's the problem ? what board did you config it for ?
05:06 < Marex> vickylinuxer: give me the exact xyz for xyz_config 05:10 < vickylinuxer> at91sam9263_nandflash
05:11 < vickylinuxer> atmel board
05:11 < Marex> compiling, checking ... please wait
05:12 < Marex> I see
05:12 < Marex> vickylinuxer: it'll take a bit to fix it all ... wanna tinker with it and assist in fixing ?
05:38 < vickylinuxer> yes marex i want to update from ver 2010.09 to 2010.12..but 09 is working good...
05:39 < vickylinuxer> but when compiling uboot-12 i m getting sdram error and so on...
05:51 < Marex> vickylinuxer: ok well ... there seems to be more breakage than I expected
05:57 < Marex> vickylinuxer: try this http://pastebin.com/2Rq92nNg

//-------- DIFF ---------

config.mk +1 -1
index 5147c35..fe1d40c 100644
@@ -261,7 +261,7 @@ $(obj)%.s:  %.c
 
 # If the list of objects to link is empty, just create an empty built-in.o
 cmd_link_o_target = $(if $(strip $1),\
-                     $(LD) $(LDFLAGS) -r -o $@ $1,\
+                     $(LD) -r -o $@ $1,\
                      rm -f $@; $(AR) rcs $@ )
 
 #########################################################################
drivers/serial/atmel_usart.c +1 -0
index bfa1f3a..1cc8bc0 100644
@@ -23,6 +23,7 @@
 
 #include <asm/io.h>
 #include <asm/arch/clk.h>
+#include <asm/arch/hardware.h>
 #include <asm/arch/memory-map.h>
 
 #if defined(CONFIG_USART0)
drivers/spi/atmel_dataflash_spi.c +2 -2
index 4a5c4aa..d5215c0 100644
@@ -158,12 +158,12 @@ unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc)
        }
 
        /* arm simple, non interrupt dependent timer */
-       reset_timer_masked();
+       reset_timer();
        timeout = 0;
 
        writel(AT91_SPI_TXTEN + AT91_SPI_RXTEN, AT91_BASE_SPI + AT91_SPI_PTCR);
        while (!(readl(AT91_BASE_SPI + AT91_SPI_SR) & AT91_SPI_RXBUFF) &&
-               ((timeout = get_timer_masked()) < CONFIG_SYS_SPI_WRITE_TOUT));
+               ((timeout = get_timer(0)) < CONFIG_SYS_SPI_WRITE_TOUT));
        writel(AT91_SPI_TXTDIS + AT91_SPI_RXTDIS, AT91_BASE_SPI + 

AT91_SPI_PTCR);
        pDesc->state = IDLE;
include/configs/at91sam9263ek.h +3 -0
index f6cb406..3db8bd0 100644
@@ -27,6 +27,9 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#define CONFIG_AT91_LEGACY
+#define        CONFIG_AT91FAMILY
+
 /* ARM asynchronous clock */
 #define CONFIG_SYS_AT91_MAIN_CLOCK     16367660        /* 16.367 MHz crystal */
 #define CONFIG_SYS_HZ          1000

@@ -341,6 +344,10 @@
  */
 #define CONFIG_SYS_MALLOC_LEN          ROUND(3 * CONFIG_ENV_SIZE + 128*1024,

0x1000)

+#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000 - \
+ GENERATED_GBL_DATA_SIZE)
+
#define CONFIG_STACKSIZE (32*1024) /* regular stack */

#ifdef CONFIG_USE_IRQ

#1 lore raw

Dear Marek Vasut,

Quoted 4 lines

The problem is clear from this IRC log, where "vickylinuxer" described his grief (so I included the log, the board really doesn't build). I also did a quick and dirty patch (follows the log, it might give you an idea where it breaks, but it's a mess -- not all is relevant and it probably breaks it even more).

All ATMEL AT91 boards except for AT91SAM9260ek (which I fixed) boards are currently broken. People are working towards bringing the others in-line again, but that will take time.

drivers/serial/atmel_usart.c line 27

Quoted 10 lines
drivers/serial/atmel_usart.c +1 -0
index bfa1f3a..1cc8bc0 100644
@@ -23,6 +23,7 @@
 
 #include <asm/io.h>
 #include <asm/arch/clk.h>
+#include <asm/arch/hardware.h>
 #include <asm/arch/memory-map.h>

Things like that are fixed at u-boot-atmel.git/rework101228...

drivers/spi/atmel_dataflash_spi.c unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc) · line 161

Quoted 10 lines
drivers/spi/atmel_dataflash_spi.c +1 -1
index 4a5c4aa..d5215c0 100644
@@ -158,12 +158,12 @@ unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc)
        }
 
        /* arm simple, non interrupt dependent timer */
-       reset_timer_masked();
+       reset_timer();

NO. reset_timer() is not acceptable anymore. A fix is already in the list, I just need some time to handle it all:)

include/configs/at91sam9263ek.h line 30

Quoted 9 lines
include/configs/at91sam9263ek.h +1 -0
index f6cb406..3db8bd0 100644
@@ -27,6 +27,9 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#define CONFIG_AT91_LEGACY

There should be no need for LEGACY anymore.

I have project deadlines I must meet first, then I will handle all accumulated AT91 patches.

Best Regards,
Reinhard

#2 lore raw

[U-Boot] AT91: dataflash: was at91sam9263_nandflash build issues

Just noticed that the subject was wrong!

author
#3 lore raw
In reply to Reinhard Meyer
Quoted 2 lines · On Wednesday 02 February 2011 09:16:46 Reinhard Meyer wrote:

Dear Marek Vasut,

Hi,

Quoted 9 lines
Quoted 5 lines

The problem is clear from this IRC log, where "vickylinuxer" described his grief (so I included the log, the board really doesn't build). I also did a quick and dirty patch (follows the log, it might give you an idea where it breaks, but it's a mess -- not all is relevant and it probably breaks it even more).

All ATMEL AT91 boards except for AT91SAM9260ek (which I fixed) boards are currently broken. People are working towards bringing the others in-line again, but that will take time.

All right. No need to worry, we all are busy :)

Quoted 7 lines
Quoted 7 lines
drivers/serial/atmel_usart.c +0 -0
index bfa1f3a..1cc8bc0 100644
@@ -23,6 +23,7 @@
Quoted 8 lines

drivers/serial/atmel_usart.c

Quoted 6 lines
drivers/serial/atmel_usart.c +1 -0
 #include <asm/io.h>
 #include <asm/arch/clk.h>
 
+#include <asm/arch/hardware.h>
 
 #include <asm/arch/memory-map.h>

Things like that are fixed at u-boot-atmel.git/rework101228...

Ok, good to know.

Quoted 10 lines
Quoted 10 lines
(quoted diff) +0 -0

b/drivers/spi/atmel_dataflash_spi.c index 4a5c4aa..d5215c0 100644

drivers/spi/atmel_dataflash_spi.c +0 -0
@@ -158,12 +158,12 @@ unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc
 pDesc)
 
        }
Quoted 7 lines

drivers/spi/atmel_dataflash_spi.c unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc) · line 161

Quoted 4 lines
drivers/spi/atmel_dataflash_spi.c +1 -1
        /* arm simple, non interrupt dependent timer */
 
-       reset_timer_masked();
+       reset_timer();

NO. reset_timer() is not acceptable anymore. A fix is already in the list, I just need some time to handle it all:)

Ok, it was just a very quick thing with no thinking involved.

Quoted 10 lines
Quoted 10 lines
(quoted diff) +0 -0

b/include/configs/at91sam9263ek.h index f6cb406..3db8bd0 100644

include/configs/at91sam9263ek.h +0 -0
@@ -27,6 +27,9 @@
 
 #ifndef __CONFIG_H
 #define __CONFIG_H
Quoted 6 lines

include/configs/at91sam9263ek.h line 30

Quoted 1 line
include/configs/at91sam9263ek.h +1 -0
+#define CONFIG_AT91_LEGACY

There should be no need for LEGACY anymore.

I have project deadlines I must meet first, then I will handle all accumulated AT91 patches.

Ok, as I don't have any AT91 hardware, I can't help anymore :)

Cheers

Quoted 3 lines

Best Regards,
Reinhard

#4 lore raw
In reply to Marek Vasut

Dear Marek Vasut,

Quoted 4 lines · In message <[email protected]> you wrote:

The problem is clear from this IRC log, where "vickylinuxer" described his grief (so I included the log, the board really doesn't build). I also did a quick and dirty patch (follows the log, it might give you an idea where it breaks, but it's a mess -- not all is relevant and it probably breaks it even more).

What exactly is it that you want?

Contact the board maintainer ? Then why did you not put him on Cc: ?

Contact the responsible custodian ? Then why did you not put him on Cc: ?

Submit a fix ? Then why did you not follow the patch submission rules?

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of course there's no reason for it, it's just our policy.
#5 lore raw
In reply to Marek Vasut

config.mk $(obj)%.s: %.c · line 265

Quoted 11 lines · On Wed, 2 Feb 2011 08:49:36 +0100 Marek Vasut <[email protected]> wrote:
config.mk +1 -1
index 5147c35..fe1d40c 100644
@@ -261,7 +261,7 @@ $(obj)%.s:  %.c
 
 # If the list of objects to link is empty, just create an empty built-in.o
 cmd_link_o_target = $(if $(strip $1),\
-                     $(LD) $(LDFLAGS) -r -o $@ $1,\
+                     $(LD) -r -o $@ $1,\
                      rm -f $@; $(AR) rcs $@ )

LDFLAGS was used here deliberately by commit:
8aba9dceebb14144e07d19593111ee3a999c37fc

I suspect your problem is because you have --gc-sections in PLATFORM_LDFLAGS. The above commit changed architectures that set --gc-sections to use LDFLAGS_u-boot instead, but it missed boards that set it.

Also note this patch, which if applied would mean that you'd need to put --gc-sections in LDFLAGS_FINAL instead of LDFLAGS_u-boot:

http://patchwork.ozlabs.org/patch/81206/

-Scott

author
#6 lore raw
Quoted 12 lines · On Wednesday 02 February 2011 20:43:00 Scott Wood wrote:

On Wed, 2 Feb 2011 08:49:36 +0100

Quoted 9 lines · Marek Vasut
config.mk +0 -0
index 5147c35..fe1d40c 100644
@@ -261,7 +261,7 @@ $(obj)%.s:  %.c
 
 # If the list of objects to link is empty, just create an empty
 built-in.o cmd_link_o_target = $(if $(strip $1),\
Quoted 7 lines

config.mk $(obj)%.s: %.c

Quoted 4 lines
config.mk +1 -1
-                     $(LD) $(LDFLAGS) -r -o $@ $1,\
+                     $(LD) -r -o $@ $1,\
 
                      rm -f $@; $(AR) rcs $@ )

LDFLAGS was used here deliberately by commit:
8aba9dceebb14144e07d19593111ee3a999c37fc

Oh my, it's not my platform. Also, you missed the comment where I said the patch is a mess, not a patch to be merged :) This time I really only forwarded a bugreport from irc channel with a bad sketch of a patch.

Quoted 12 lines

I suspect your problem is because you have --gc-sections in PLATFORM_LDFLAGS. The above commit changed architectures that set --gc-sections to use LDFLAGS_u-boot instead, but it missed boards that set it.

Also note this patch, which if applied would mean that you'd need to put --gc-sections in LDFLAGS_FINAL instead of LDFLAGS_u-boot:

http://patchwork.ozlabs.org/patch/81206/

-Scott