[U-Boot] Fixing IXP42x boards - some general questions

[U-Boot] Fixing IXP42x boards - some general questions

[Michael Schwingen]

Hi,

I am in the process of fixing the actux-* boards, which were broken by
the introduction of ARM relocation.

However, it seems the IPX platform is broken beyond those problems
introduced by relocation support, so I have some general questions on
how things are supposed to work. I have a working set of patches for
actux-3, but I want to make sure I use the right approach before fixing
the other boards and submitting patches.

Startup code. Is the following correct?
 - code starts from flash, with TEXT_BASE = start of flash, ie. the code
is linked to flash addresses.
 - DATA/BSS are behind the text segment in flash, so the code may not
write RAM variables until relocation
 - code in flash sets up RAM, copies + relocates u-boot to RAM, and
continues there

Timer system.
 - For IXP, there are two variants of the timer system - one using
interrupts, and one without interrupts. Both do not work currently.
I have patches that fix the non-interrupt version, changing
CONFIG_SYS_HZ from 66666666 to 1000, bringing it in line with what most
other ARM platforms do.
What is the preferred way of handling timers? Should CONFIG_SYS_HZ be
1000 or rather the timer clock?
What about interrupts? Use them or avoid them?

What about the Intel reference board (IXDP425)? Previously, I used that
one as a reference on how things should be done, but it looks broken, too.
I can prepare patches for IXDP425, but I can't currently test them (we
should have one at work, but that might take some time).

cu
Michael

[U-Boot] Fixing IXP42x boards - some general questions

[Wolfgang Denk]

Dear Michael Schwingen,

In message <4D13175F.8030207@discworld.dascon.de> you wrote:
> 
> Startup code. Is the following correct?
>  - code starts from flash, with TEXT_BASE = start of flash, ie. the code
> is linked to flash addresses.

Correct.

>  - DATA/BSS are behind the text segment in flash, so the code may not
> write RAM variables until relocation

Correct.

In addition, BSS is not initialized yet, so you should not even try
reading variables in BSS, as these will contain random data.  This
affects especially static variables that are supposed to be
initialized with zero.

>  - code in flash sets up RAM, copies + relocates u-boot to RAM, and
> continues there

Correct.

> Timer system.
>  - For IXP, there are two variants of the timer system - one using
> interrupts, and one without interrupts. Both do not work currently.
> I have patches that fix the non-interrupt version, changing
> CONFIG_SYS_HZ from 66666666 to 1000, bringing it in line with what most
> other ARM platforms do.

I cannot nomment on this.  Marek?

> What is the preferred way of handling timers? Should CONFIG_SYS_HZ be
> 1000 or rather the timer clock?

CONFIG_SYS_HZ must always be defiend as 1000.

> What about interrupts? Use them or avoid them?

If you can do without interrupts, I would do that, because it's
simpler.

> What about the Intel reference board (IXDP425)? Previously, I used that
> one as a reference on how things should be done, but it looks broken, too.
> I can prepare patches for IXDP425, but I can't currently test them (we
> should have one at work, but that might take some time).

I cannot help with that either.  Marek?

Best regards,

Wolfgang Denk

-- 
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
Never call a man a fool.  Borrow from him.

[U-Boot] Fixing IXP42x boards - some general questions

[Marek Vasut]

On Thursday 23 December 2010 11:10:37 Wolfgang Denk wrote:
> Dear Michael Schwingen,
> 
> In message <4D13175F.8030207@discworld.dascon.de> you wrote:
> > Startup code. Is the following correct?
> > 
> >  - code starts from flash, with TEXT_BASE = start of flash, ie. the code
> > 
> > is linked to flash addresses.
> 
> Correct.
> 
> >  - DATA/BSS are behind the text segment in flash, so the code may not
> > 
> > write RAM variables until relocation
> 
> Correct.
> 
> In addition, BSS is not initialized yet, so you should not even try
> reading variables in BSS, as these will contain random data.  This
> affects especially static variables that are supposed to be
> initialized with zero.
> 
> >  - code in flash sets up RAM, copies + relocates u-boot to RAM, and
> > 
> > continues there
> 
> Correct.
> 
> > Timer system.
> > 
> >  - For IXP, there are two variants of the timer system - one using
> > 
> > interrupts, and one without interrupts. Both do not work currently.
> > I have patches that fix the non-interrupt version, changing
> > CONFIG_SYS_HZ from 66666666 to 1000, bringing it in line with what most
> > other ARM platforms do.
> 
> I cannot nomment on this.  Marek?

http://download.intel.com/design/network/manuals/25248006.pdf page 411 or so.

What's the second variant ? Either way -- you should use the non-interrupt 
version. Remember, you're writing a bootloader, use the KISS principle ; you 
generally use the timer only to implement *delay() functions.

Therefore, as Wolfgang said, you use 1000 ticks per second in uboot's internal 
counting, but "convert" it from/to your real timer's ticks in timer.c

What problem do you have there? Also, can you please let us see the patches?
> 
> > What is the preferred way of handling timers? Should CONFIG_SYS_HZ be
> > 1000 or rather the timer clock?
> 
> CONFIG_SYS_HZ must always be defiend as 1000.
> 
> > What about interrupts? Use them or avoid them?
> 
> If you can do without interrupts, I would do that, because it's
> simpler.
> 
> > What about the Intel reference board (IXDP425)? Previously, I used that
> > one as a reference on how things should be done, but it looks broken,
> > too. I can prepare patches for IXDP425, but I can't currently test them
> > (we should have one at work, but that might take some time).
> 
> I cannot help with that either.  Marek?

Go ahead, patches are welcome. I don't have any ixp hardware, but it looks fairy 
similar to pxa, it should be easy to review patches.
> 
> Best regards,
> 
> Wolfgang Denk

Cheers

[U-Boot] Fixing IXP42x boards - some general questions

[Michael Schwingen]

On Thu, Dec 23, 2010 at 11:55:01AM +0100, Marek Vasut wrote:
> On Thursday 23 December 2010 11:10:37 Wolfgang Denk wrote:
> > 
> > > Timer system.
> > > 
> > >  - For IXP, there are two variants of the timer system - one using
> > > 
> > > interrupts, and one without interrupts. Both do not work currently.
> > > I have patches that fix the non-interrupt version, changing
> > > CONFIG_SYS_HZ from 66666666 to 1000, bringing it in line with what most
> > > other ARM platforms do.
> > 
> > I cannot nomment on this.  Marek?
> 
> http://download.intel.com/design/network/manuals/25248006.pdf page 411 or so.
> 
> What's the second variant ? Either way -- you should use the non-interrupt 
> version. Remember, you're writing a bootloader, use the KISS principle ; you 
> generally use the timer only to implement *delay() functions.
> 
> Therefore, as Wolfgang said, you use 1000 ticks per second in uboot's internal 
> counting, but "convert" it from/to your real timer's ticks in timer.c
> 
> What problem do you have there? Also, can you please let us see the patches?

I don't have any problems - I just want to know what the preferred way is in
doing this, before I spend time touching multiple boards.

Patch for the timer part is attached - note that this is work-in-progress
and probably needs some cleanup before submission.

cu
Michael



diff --git a/arch/arm/cpu/ixp/timer.c b/arch/arm/cpu/ixp/timer.c
index edf341f..9715eab 100644
--- a/arch/arm/cpu/ixp/timer.c
+++ b/arch/arm/cpu/ixp/timer.c
@@ -1,4 +1,7 @@
 /*
+ * (C) Copyright 2010
+ * Michael Schwingen, michael at schwingen.org
+ *
  * (C) Copyright 2006
  * Stefan Roese, DENX Software Engineering, sr at denx.de.
  *
@@ -31,11 +34,11 @@
 
 #include <common.h>
 #include <asm/arch/ixp425.h>
+#include <div64.h>
 
 #ifdef CONFIG_TIMER_IRQ
 
-#define FREQ		66666666
-#define CLOCK_TICK_RATE	(((FREQ / CONFIG_SYS_HZ & ~IXP425_OST_RELOAD_MASK) + 1) * CONFIG_SYS_HZ)
+#define CLOCK_TICK_RATE	(((CONFIG_IXP425_TIMER_CLK / CONFIG_SYS_HZ & ~IXP425_OST_RELOAD_MASK) + 1) * CONFIG_SYS_HZ)
 #define LATCH		((CLOCK_TICK_RATE + CONFIG_SYS_HZ/2) / CONFIG_SYS_HZ)	/* For divider */
 
 /*
@@ -79,57 +82,98 @@ int timer_init (void)
 
 	return 0;
 }
-#else
-ulong get_timer (ulong base)
+
+#else /* not CONFIG_TIMER_IRQ */
+
+/*
+ * The IXP42x time-stamp timer runs at 2*OSC_IN (66.666MHz when using a
+ * 33.333MHz crystal).
+ */
+static inline unsigned long long tick_to_time(unsigned long long tick)
 {
-       return get_timer_masked () - base;
+	tick *= CONFIG_SYS_HZ;
+	do_div(tick, CONFIG_IXP425_TIMER_CLK);
+	return tick;
 }
 
-void ixp425_udelay(unsigned long usec)
+static inline unsigned long long time_to_tick(unsigned long long time)
 {
-	/*
-	 * This function has a max usec, but since it is called from udelay
-	 * we should not have to worry... be happy
-	 */
-	unsigned long usecs = CONFIG_SYS_HZ/1000000L & ~IXP425_OST_RELOAD_MASK;
+	time *= CONFIG_IXP425_TIMER_CLK;
+	do_div(time, CONFIG_SYS_HZ);
+	return time;
+}
 
-	*IXP425_OSST = IXP425_OSST_TIMER_1_PEND;
-	usecs |= IXP425_OST_ONE_SHOT | IXP425_OST_ENABLE;
-	*IXP425_OSRT1 = usecs;
-	while (!(*IXP425_OSST & IXP425_OSST_TIMER_1_PEND));
+static inline unsigned long long us_to_tick(unsigned long long us)
+{
+	us = us * CONFIG_IXP425_TIMER_CLK + 999999;
+	do_div(us, 1000000);
+	return us;
 }
 
-void __udelay (unsigned long usec)
+static ulong timestamp;
+static ulong lastinc;
+
+unsigned long long get_ticks (void)
 {
-	while (usec--) ixp425_udelay(1);
+	ulong now = *IXP425_OSTS_B;
+
+	if (*IXP425_OSST & IXP425_OSST_TIMER_TS_PEND) {
+		/* rollover of timestamp timer register */
+		timestamp += (0xFFFFFFFF - lastinc) + now + 1;
+		*IXP425_OSST = IXP425_OSST_TIMER_TS_PEND;
+	}
+	else {
+		/* move stamp forward with absolut diff ticks */
+		timestamp += (now - lastinc);
+	}
+	lastinc = now;
+	return timestamp;
 }
 
-static ulong reload_constant = 0xfffffff0;
 
 void reset_timer_masked (void)
 {
-	ulong reload = reload_constant | IXP425_OST_ONE_SHOT | IXP425_OST_ENABLE;
+	/* reset time */
+	lastinc = *IXP425_OSTS_B; /* capture current timestamp counter */
+	timestamp = 0;          /* start "advancing" time stamp from 0 */
+}
 
-	*IXP425_OSST = IXP425_OSST_TIMER_1_PEND;
-	*IXP425_OSRT1 = reload;
+void reset_timer(void)
+{
+	reset_timer_masked();
 }
 
 ulong get_timer_masked (void)
 {
-	/*
-	 * Note that it is possible for this to wrap!
-	 * In this case we return max.
-	 */
-	ulong current = *IXP425_OST1;
-	if (*IXP425_OSST & IXP425_OSST_TIMER_1_PEND)
-	{
-		return reload_constant;
-	}
-	return (reload_constant - current);
+	return tick_to_time(get_ticks());
+}
+
+ulong get_timer (ulong base)
+{
+	return get_timer_masked() - base;
+}
+
+void set_timer (ulong t)
+{
+	timestamp = time_to_tick(t);
 }
 
+/* delay x useconds AND preserve advance timestamp value */
+void __udelay (unsigned long usec)
+{
+	unsigned long long tmp;
+
+	tmp = get_ticks() + us_to_tick(usec);
+
+	while (get_ticks() < tmp)
+		;
+}
+
+
 int timer_init(void)
 {
+	*IXP425_OSST = IXP425_OSST_TIMER_TS_PEND;
 	return 0;
 }
+
 #endif
diff --git a/arch/arm/include/asm/arch-ixp/ixp425.h b/arch/arm/include/asm/arch-ixp/ixp425.h
index 2114437..ddbf713 100644
--- a/arch/arm/include/asm/arch-ixp/ixp425.h
+++ b/arch/arm/include/asm/arch-ixp/ixp425.h
@@ -391,9 +391,8 @@
 #define IXP425_TIMER_REG(x) (IXP425_TIMER_BASE_PHYS+(x))
 #endif
 
-#if 0 /* test-only: also defined in npe/include/... */
-#define IXP425_OSTS	IXP425_TIMER_REG(IXP425_OSTS_OFFSET)
-#endif
+/* _B to avoid collision: also defined in npe/include/... */
+#define IXP425_OSTS_B	IXP425_TIMER_REG(IXP425_OSTS_OFFSET) 
 #define IXP425_OST1	IXP425_TIMER_REG(IXP425_OST1_OFFSET)
 #define IXP425_OSRT1	IXP425_TIMER_REG(IXP425_OSRT1_OFFSET)
 #define IXP425_OST2	IXP425_TIMER_REG(IXP425_OST2_OFFSET)
diff --git a/include/configs/actux3.h b/include/configs/actux3.h
index 76acf5a..4afe5ac 100644
--- a/include/configs/actux3.h
+++ b/include/configs/actux3.h
@@ -28,6 +28,7 @@
 
 #define CONFIG_IXP425			1
 #define CONFIG_ACTUX3			1
+#define CONFIG_USE_FUNCTION_SECTIONS    1
 
 #define CONFIG_DISPLAY_CPUINFO		1
 #define CONFIG_DISPLAY_BOARDINFO	1
@@ -37,6 +38,7 @@
 #define CONFIG_BAUDRATE			115200
 #define CONFIG_BOOTDELAY		3
 #define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on bootdelay==0 */
+#define CONFIG_BOARD_EARLY_INIT_F	1
 
 /***************************************************************
  * U-boot generic defines start here.
@@ -83,8 +85,9 @@
 #define CONFIG_SYS_MEMTEST_START		0x00400000
 #define CONFIG_SYS_MEMTEST_END			0x00800000
 
-/* spec says 66.666 MHz, but it appears to be 33 */
-#define CONFIG_SYS_HZ				3333333
+/* timer clock - 2* OSC_IN system clock */
+#define CONFIG_IXP425_TIMER_CLK                 66666666
+#define CONFIG_SYS_HZ				1000
 
 /* default load address */
 #define CONFIG_SYS_LOAD_ADDR			0x00010000
@@ -111,7 +114,7 @@
 /* SDRAM settings */
 #define CONFIG_NR_DRAM_BANKS		1
 #define PHYS_SDRAM_1			0x00000000
-#define CONFIG_SYS_DRAM_BASE			0x00000000
+#define CONFIG_SYS_SDRAM_BASE			0x00000000
 
 /* 16MB SDRAM */
 #define CONFIG_SYS_SDR_CONFIG			0x3A
@@ -121,6 +124,7 @@
 #define CONFIG_SYS_DRAM_SIZE			0x01000000
 
 /* FLASH organization */
+#define CONFIG_SYS_TEXT_BASE		0x50000000
 #define CONFIG_SYS_MAX_FLASH_BANKS		1
 /* max number of sectors on one chip */
 #define CONFIG_SYS_MAX_FLASH_SECT		140
@@ -150,6 +154,11 @@
 #define	CONFIG_PHY_ADDR			0x10
 /* MII PHY management */
 #define CONFIG_MII			1
+/* fixed-speed switch without standard PHY registers on MII */
+#define CONFIG_MII_NPE0_FIXEDLINK       1
+#define CONFIG_MII_NPE0_SPEED           100
+#define CONFIG_MII_NPE0_FULLDUPLEX      1
+
 /* Number of ethernet rx buffers & descriptors */
 #define CONFIG_SYS_RX_ETH_BUFFER		16
 #define CONFIG_RESET_PHY_R		1
@@ -223,4 +232,8 @@
 	" tftpboot ${loadaddr} ${kernelfile};"				\
 	" bootm\0"
 
+/* additions for new relocation code, must be added to all boards */
+#define CONFIG_SYS_INIT_SP_ADDR        \
+	(CONFIG_SYS_SDRAM_BASE + 0x1000 - GENERATED_GBL_DATA_SIZE)
+
 #endif /* __CONFIG_H */

[U-Boot] Fixing IXP42x boards - some general questions

[Michael Schwingen]

Am 12/23/2010 11:10 AM, schrieb Wolfgang Denk:
>
>> Timer system.
>>  - For IXP, there are two variants of the timer system - one using
>> interrupts, and one without interrupts. Both do not work currently.
>> I have patches that fix the non-interrupt version, changing
>> CONFIG_SYS_HZ from 66666666 to 1000, bringing it in line with what most
>> other ARM platforms do.
> I cannot nomment on this.  Marek?
>
>> What is the preferred way of handling timers? Should CONFIG_SYS_HZ be
>> 1000 or rather the timer clock?
> CONFIG_SYS_HZ must always be defiend as 1000.
Thanks - no problem for IXP42x.

There are a few non-IXP42x boards that have different values:

include/configs/lart.h:110:#define    CONFIG_SYS_HZ           
3686400        /* incrementer freq: 3.6864 MHz */
include/configs/dvlhost.h:91:#define CONFIG_SYS_HZ            3333333
include/configs/impa7.h:112:#define    CONFIG_SYS_HZ            2000   
    /* decrementer freq: 2 kHz */
include/configs/SMN42.h:143:#define    CONFIG_SYS_HZ            2048   
    /* decrementer freq in Hz */
include/configs/colibri_pxa270.h:141:#define    CONFIG_SYS_HZ           
3250000        /* Timer @ 3250000 Hz */
include/configs/lpc2292sodimm.h:110:#define    CONFIG_SYS_HZ           
2048        /* decrementer freq in Hz */
include/configs/mx1fs2.h:80:#define CONFIG_SYS_HZ            3686400   
     /* incrementer freq: 3.6864 MHz */
include/configs/scb9328.h:87:#define CONFIG_SYS_HZ            3686400   
     /* incrementer freq: 3.6864 MHz */
include/configs/mx1ads.h:134:#define CONFIG_SYS_HZ            3686400
include/configs/modnet50.h:116:#define    CONFIG_SYS_HZ           
900        /* decrementer freq: 2 kHz */
include/configs/armadillo.h:111:#define    CONFIG_SYS_HZ           
2000        /* decrementer freq: 2 kHz */
include/configs/assabet.h:113:#define CONFIG_SYS_HZ           
3686400    /* incrementer freq: 3.6864 MHz */
include/configs/lpd7a404-10.h:37:#define CONFIG_SYS_HZ    (508469)
include/configs/palmtc.h:132:#define    CONFIG_SYS_HZ           
3686400        /* Timer @ 3686400 Hz */
include/configs/idmr.h:148:#define CONFIG_SYS_HZ            (50000000 / 64)
include/configs/KAREF.h:303:#define CONFIG_SYS_HZ              100   
     /* decr freq: 1 ms ticks    */
include/configs/gcplus.h:125:#define    CONFIG_SYS_HZ           
3686400        /* incrementer freq: 3.6864 MHz */
include/configs/ep7312.h:113:#define    CONFIG_SYS_HZ            2000   
    /* decrementer freq: 2 kHz */
include/configs/lpd7a400-10.h:37:#define CONFIG_SYS_HZ    (508469)
include/configs/shannon.h:111:#define    CONFIG_SYS_HZ           
3686400        /* incrementer freq: 3.6864 MHz */
include/configs/METROBOX.h:368:#define CONFIG_SYS_HZ              100   
     /* decr freq: 1 ms ticks    */
include/configs/palmld.h:131:#define    CONFIG_SYS_HZ           
3250000        /* Timer @ 3250000 Hz */
include/configs/dnp1110.h:116:#define    CONFIG_SYS_HZ           
3686400        /* incrementer freq: 3.6864 MHz */
include/configs/zipitz2.h:152:#define    CONFIG_SYS_HZ           
3250000        /* Timer @ 3250000 Hz */
include/configs/balloon3.h:103:#define    CONFIG_SYS_HZ           
3250000        /* Timer @ 3250000 Hz */
include/configs/VCMA9.h:179:#define    CONFIG_SYS_HZ            1562500


>
>> What about the Intel reference board (IXDP425)? Previously, I used that
>> one as a reference on how things should be done, but it looks broken, too.
>> I can prepare patches for IXDP425, but I can't currently test them (we
>> should have one at work, but that might take some time).
> I cannot help with that either.  Marek?
If noone else steps up and the board would be removed from u-boot, you
can list me as maintainer, but I can't test too often.

cu
Michael

[U-Boot] Fixing IXP42x boards - some general questions

[Albert ARIBAUD]

Hi Michael,

Answering as the brand new ARM custodian :) :

Le 23/12/2010 10:33, Michael Schwingen a ?crit :

> Startup code. Is the following correct?
>   - code starts from flash, with TEXT_BASE = start of flash, ie. the code
> is linked to flash addresses.

Correct.  The goal of ELF relocation is to allow moving the code from 
FLASH to any place in RAM (actually the highest possible location) by 
correctly relocating it without developers having to fix or code 
anything manually.

>   - DATA/BSS are behind the text segment in flash, so the code may not
> write RAM variables until relocation

Actually in FLASH there is no BSS at all -- you cannot use BSS until 
after relocation (this was already a constraint in u-boot, even though 
before ELF relocation ARM architecture did not make it impossible.

FYI, the BSS location in FLASH is actually occupied by the relocation 
tables.

DATA (especially const data) are available, though, read-only.

Any RW data that you absolutely need to set before relocation and access 
after it, you need to put in the GD structure.

>   - code in flash sets up RAM, copies + relocates u-boot to RAM, and
> continues there

Correct. Rule of thumb is init_board_f() runs in Flash, and 
init_board_r() runs in RAM.

> Timer system.
>   - For IXP, there are two variants of the timer system - one using
> interrupts, and one without interrupts. Both do not work currently.
> I have patches that fix the non-interrupt version, changing
> CONFIG_SYS_HZ from 66666666 to 1000, bringing it in line with what most
> other ARM platforms do.
> What is the preferred way of handling timers? Should CONFIG_SYS_HZ be
> 1000 or rather the timer clock?
> What about interrupts? Use them or avoid them?

I say in any case don't use them before running from RAM; and if you can 
avoid them in u-boot without incurring a huge performance penalty, I 
would suggest avoiding them altogether.

Amicalement,
-- 
Albert.

[U-Boot] Fixing IXP42x boards - some general questions

[Michael Schwingen]

Am 12/23/2010 11:20 AM, schrieb Albert ARIBAUD:
> Hi Michael,
>
> Answering as the brand new ARM custodian :) :
>
> Le 23/12/2010 10:33, Michael Schwingen a ?crit :
>
>> Startup code. Is the following correct?
>>   - code starts from flash, with TEXT_BASE = start of flash, ie. the code
>> is linked to flash addresses.
> Correct.  The goal of ELF relocation is to allow moving the code from 
> FLASH to any place in RAM (actually the highest possible location) by 
> correctly relocating it without developers having to fix or code 
> anything manually.
Thanks. That means the code in the IXP startup code that copies flash to
RAM (before calling board_init_f, and long before relocation code does a
second copy) is really not needed, and can be removed if the branch to
the reset code is replaced by an absolute jump to the real
(not-aliased-to zero) flash location.


>>   - DATA/BSS are behind the text segment in flash, so the code may not
>> write RAM variables until relocation
> Actually in FLASH there is no BSS at all -- you cannot use BSS until 
> after relocation (this was already a constraint in u-boot, even though 
> before ELF relocation ARM architecture did not make it impossible.
I am asking because there *was* code in print_cpuinfo which writes
global variables, and which is called before relocation.
So that is definitely broken (and easy to fix).


> Correct. Rule of thumb is init_board_f() runs in Flash, and
> init_board_r() runs in RAM.
Fine. It seems some initialization order was changed - I had to
introduce a board_init_early_f function and move the localbus chip
select set-up there.

>> Timer system.
>>   - For IXP, there are two variants of the timer system - one using
>> interrupts, and one without interrupts. Both do not work currently.
>> I have patches that fix the non-interrupt version, changing
>> CONFIG_SYS_HZ from 66666666 to 1000, bringing it in line with what most
>> other ARM platforms do.
>> What is the preferred way of handling timers? Should CONFIG_SYS_HZ be
>> 1000 or rather the timer clock?
>> What about interrupts? Use them or avoid them?
> I say in any case don't use them before running from RAM; and if you can 
> avoid them in u-boot without incurring a huge performance penalty, I 
> would suggest avoiding them altogether.
Fine with me. I got the non-interrupt code running, and will simply
leave the (broken) interrupt code as is if that is OK.

cu
Michael

[U-Boot] Fixing IXP42x boards - some general questions

[Albert ARIBAUD]

Le 23/12/2010 11:39, Michael Schwingen a ?crit :
> Am 12/23/2010 11:20 AM, schrieb Albert ARIBAUD:
>> Hi Michael,
>>
>> Answering as the brand new ARM custodian :) :
>>
>> Le 23/12/2010 10:33, Michael Schwingen a ?crit :
>>
>>> Startup code. Is the following correct?
>>>    - code starts from flash, with TEXT_BASE = start of flash, ie. the code
>>> is linked to flash addresses.
>> Correct.  The goal of ELF relocation is to allow moving the code from
>> FLASH to any place in RAM (actually the highest possible location) by
>> correctly relocating it without developers having to fix or code
>> anything manually.
> Thanks. That means the code in the IXP startup code that copies flash to
> RAM (before calling board_init_f, and long before relocation code does a
> second copy) is really not needed, and can be removed if the branch to
> the reset code is replaced by an absolute jump to the real
> (not-aliased-to zero) flash location.

As for the additional copy, yes, it is uneeded -- look at some 
ARM-based archs or boards which support ELF relocation (such as arm926ejs).

As for the jump, 'b' instruction is relative, and there is no need to 
make an absolute jump -- unless you boot in a weird mode where FLASH 
mirrors all over the memory space (and over RAM) and you need to jump to 
the 'real', not 'mirrored', FLASH?

>>> What about interrupts? Use them or avoid them?
>> I say in any case don't use them before running from RAM; and if you can
>> avoid them in u-boot without incurring a huge performance penalty, I
>> would suggest avoiding them altogether.

> Fine with me. I got the non-interrupt code running, and will simply
> leave the (broken) interrupt code as is if that is OK.

Maybe it would be better to remove it. If someone really feels the need 
to revive it, they can copy back it from a previous commit where it 
still exists.

> cu
> Michael

Amicalement,
-- 
Albert.

[U-Boot] Fixing IXP42x boards - some general questions

[Michael Schwingen]

Am 12/23/2010 12:28 PM, schrieb Albert ARIBAUD:
>> Thanks. That means the code in the IXP startup code that copies flash to
>> RAM (before calling board_init_f, and long before relocation code does a
>> second copy) is really not needed, and can be removed if the branch to
>> the reset code is replaced by an absolute jump to the real
>> (not-aliased-to zero) flash location.
> As for the additional copy, yes, it is uneeded -- look at some 
> ARM-based archs or boards which support ELF relocation (such as arm926ejs).
>
> As for the jump, 'b' instruction is relative, and there is no need to 
> make an absolute jump -- unless you boot in a weird mode where FLASH 
> mirrors all over the memory space (and over RAM) and you need to jump to 
> the 'real', not 'mirrored', FLASH?
This is the case on IXP: the boot flash is located at 0x50000000 on the
expansion bus.
At reset, the flash is mirrored to 0x00000000, and the code starts
there. Later, the startup code removes that mirror so that the SDRAM is
at 0x00000000.

Currently, this works because the code copies u-boot from flash to
0x00000000 before disabling the mirror. However, a simple jump to
0x50000000 + offset works just as well (and is easier, because debug
symbols match execution).


>>>> What about interrupts? Use them or avoid them?
>>> I say in any case don't use them before running from RAM; and if you can
>>> avoid them in u-boot without incurring a huge performance penalty, I
>>> would suggest avoiding them altogether.
>> Fine with me. I got the non-interrupt code running, and will simply
>> leave the (broken) interrupt code as is if that is OK.
> Maybe it would be better to remove it. If someone really feels the need 
> to revive it, they can copy back it from a previous commit where it 
> still exists.
Fine with me. I don't really see why interrupts should be needed inside
u-boot on IXP425.

cu
Michael

[U-Boot] Fixing IXP42x boards - some general questions

[Michael Schwingen]

Am 12/23/2010 12:28 PM, schrieb Albert ARIBAUD:
>
>
>>>> What about interrupts? Use them or avoid them?
>>> I say in any case don't use them before running from RAM; and if you can
>>> avoid them in u-boot without incurring a huge performance penalty, I
>>> would suggest avoiding them altogether.
>> Fine with me. I got the non-interrupt code running, and will simply
>> leave the (broken) interrupt code as is if that is OK.
> Maybe it would be better to remove it. If someone really feels the need 
> to revive it, they can copy back it from a previous commit where it 
> still exists.
OK. It seems the interrupt code is more broken than I thought - the
udelay implementation relies on a variable that is set *before*
relocation - in BSS.

Rather than trying to fix this, I will remove the broken parts.

I'll do some more cleanup next week, test all boards I have here, and
post patches for review.

cu
Michael

[U-Boot] Fixing IXP42x boards - some general questions

[Albert ARIBAUD]

Le 23/12/2010 19:25, Michael Schwingen a ?crit :

> OK. It seems the interrupt code is more broken than I thought - the
> udelay implementation relies on a variable that is set *before*
> relocation - in BSS.

And the non-interrupt code does not?

Amicalement,
-- 
Albert.

[U-Boot] Fixing IXP42x boards - some general questions

[Michael Schwingen]

Am 12/23/2010 07:47 PM, schrieb Albert ARIBAUD:
> Le 23/12/2010 19:25, Michael Schwingen a ?crit :
>
>> OK. It seems the interrupt code is more broken than I thought - the
>> udelay implementation relies on a variable that is set *before*
>> relocation - in BSS.
> And the non-interrupt code does not?
No. After the rewrite, the code does delay-to-timer-tic conversion and
uses the timebase counter in the IXP (which always counts up, with a
fixed rate, and has an overflow flag) to do the timing.

cu
Michael