Add board voiceblue

Hi Wolfgang,

this patch adds support for OMAP5910 based board Voiceblue. Small flash configuration will not work in tree because it needs small patch to cpu/arm925t/start.S which I sent on 12 Jan 2005 under subject "Lowering memory footprint" and nobody commented it so far. It shouldn't matter anyway, because you told me that such configuration is not supported. I'll be happy enough if you apply my other patches, all mostly oneliners. Lower memory footprint can wait, because I doubt anyone needs it.

Best regards (and thanks for nice piece of software),
ladis

CHANGELOG
* Patch by Ladislav Michl, 05 Apr 2005:
Add support for VoiceBlue board.

Index: Makefile
===================================================================
RCS file: /cvsroot/u-boot/u-boot/Makefile,v
retrieving revision 1.171

diff -u -r1.171 Makefile
@@ -1333,6 +1333,21 @@
 	fi;
 	@./mkconfig -a $(call xtract_omap730p2,$@) arm arm926ejs omap730p2
 
+# Voiceblue default configuration: 32 MB flash, 64MB RAM
+# smallflash: 1 MB flash, running from internal 192 kB SRAM
+voiceblue_smallflash_config	\
+voiceblue_config:	unconfig
+	@if [ "$(findstring _smallflash_,$@)" ] ; then \
+		echo "... boot from lower flash bank" ; \
+		echo "#define VOICEBLUE_SMALL_FLASH" >>include/config.h ; \
+		echo "VOICEBLUE_SMALL_FLASH=y" >board/voiceblue/config.tmp ; \
+	else \
+		echo "... boot from upper flash bank" ; \
+		>include/config.h ; \
+		echo "VOICEBLUE_SMALL_FLASH=n" >board/voiceblue/config.tmp ; \
+	fi
+	@./mkconfig -a voiceblue arm arm925t voiceblue
+
 scb9328_config	:	unconfig
 	@./mkconfig $(@:_config=) arm arm920t scb9328 NULL imx
 

@@ -0,0 +1,16 @@
+#
+# Linux-Kernel is expected to be at 1000'8000,
+# entry 1000'8000 (mem base + reserved)
+#
+
+sinclude $(TOPDIR)/board/$(BOARDDIR)/config.tmp
+
+ifeq ($(VOICEBLUE_SMALL_FLASH),y)
+# We load ourself to internal SRAM at 2001'2000
+# Check map file when changing TEXT_BASE.
+# Everything has fit into 192kB internal SRAM!
+TEXT_BASE = 0x20012000
+else
+# Running in SDRAM...
+TEXT_BASE = 0x13000000
+endif

Added, but please stick to the Coding Style (no trailing white space etc.)

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
No question is too silly to ask. Of course, some  questions  are  too
silly to to answer...  - L. Wall & R. L. Schwartz, _Programming Perl_

Dear Ladislav,

The code does not compile at all:

-> MAKEALL voiceblue
... boot from upper flash bank
Configuring for voiceblue board...
/home/wd/u-boot/cpu/arm925t/start.S: Assembler messages:
/home/wd/u-boot/cpu/arm925t/start.S:193: Error: invalid constant -- sub r0,r0,#(0x00400000-128)' /home/wd/u-boot/cpu/arm925t/start.S:358: Error: invalid constant -- sub r13,r13,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:359: Error: invalid constant -- sub r2,r2,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:364: Error: invalid constant -- sub r13,r13,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:365: Error: invalid constant -- sub r2,r2,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:370: Error: invalid constant -- sub r13,r13,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:371: Error: invalid constant -- sub r2,r2,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:376: Error: invalid constant -- sub r13,r13,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:377: Error: invalid constant -- sub r2,r2,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:382: Error: invalid constant -- sub r13,r13,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:383: Error: invalid constant -- sub r2,r2,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:407: Error: invalid constant -- sub r13,r13,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:408: Error: invalid constant -- sub r2,r2,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:413: Error: invalid constant -- sub r13,r13,#(0x00002000+(0x00400000-128))' /home/wd/u-boot/cpu/arm925t/start.S:414: Error: invalid constant -- `sub r2,r2,#(0x00002000+(0x00400000-128))'
make: *** [cpu/arm925t/start.o] Error 1

Please fix.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
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

Dear Wolfgang,

					  [1] - ^^^^^^^^^^^^^^^^^^^^

[snip]

I'm sorry about that. I forgot to test patch without my change to start.S. Perhaps it's time to discuss it again (well, in fact there was no discussion so far), so I'll send it in separate mail. Here is a fix. Please note that "smallflash" configuration will be still broken.

Best regards,
ladis

Index: include/configs/voiceblue.h
===================================================================
RCS file: /cvsroot/u-boot/u-boot/include/configs/voiceblue.h,v retrieving revision 1.1

diff -u -r1.1 voiceblue.h
@@ -98,21 +98,18 @@
 #endif
 
 /*
- * Size of malloc() pool
+ * Size of malloc() pool and stack
  */
 #define CFG_GBL_DATA_SIZE	128	/* size in bytes reserved for initial data */
 #ifdef VOICEBLUE_SMALL_FLASH
 #define CFG_MALLOC_LEN		(SZ_64K - CFG_GBL_DATA_SIZE)
+#define CONFIG_STACKSIZE	SZ_8K
 #else
-#define CFG_MALLOC_LEN		(SZ_4M - CFG_GBL_DATA_SIZE)
+#define CFG_MALLOC_LEN		SZ_4M
+#define CONFIG_STACKSIZE	SZ_1M
 #endif
 
 /*
- * The stack size is set up in start.S using the settings below
- */
-#define CONFIG_STACKSIZE	SZ_8K	/* regular stack */
-
-/*
  * Hardware drivers
  */
 #define CONFIG_DRIVER_SMC91111

@@ -163,7 +160,7 @@
 #ifdef VOICEBLUE_SMALL_FLASH
 #define CONFIG_BOOTDELAY	0
 #undef  CONFIG_BOOTARGS		/* the preboot command will set bootargs*/
-#define CFG_AUTOLOAD		"n"	/* No autoload */
+#define CFG_AUTOLOAD		"n"	/* no autoload */
 #define CONFIG_PREBOOT		"run setup"
 #define	CONFIG_EXTRA_ENV_SETTINGS				\
 	"setup=setenv bootargs console=ttyS0,$(baudrate) "	\

@@ -172,8 +169,8 @@
 		"cp.b 10400000 c000000 $(filesize)\0"
 #else
 #define CONFIG_BOOTDELAY	3
-#undef  CONFIG_BOOTARGS		/* the boot command will set bootargs*/
-#define CFG_AUTOLOAD		"n"	/* No autoload */
+#undef  CONFIG_BOOTARGS		/* boot command will set bootargs */
+#define CFG_AUTOLOAD		"n"	/* no autoload */
 #define CONFIG_BOOTCOMMAND	"run nboot"
 #define CONFIG_PREBOOT		"run setup"
 #define	CONFIG_EXTRA_ENV_SETTINGS				\

@@ -188,11 +185,11 @@
 	"fi\0"							\
 	"setup=setenv bootargs console=ttyS0,$baudrate "	\
 		"mtdparts=$mtdparts\0"				\
-	"nfsargs=setenv bootargs $bootargs "			\
-		"root=/dev/nfs ip=dhcp; run setpart\0"			\
-	"flashargs=setenv bootargs $bootargs "			\
-		"root=/dev/mtdblock$partition "			\
-		"rootfstype=jffs2; run setpart\0"				\
+	"nfsargs=run setpart; setenv bootargs $bootargs "	\
+		"root=/dev/nfs ip=dhcp\0"			\
+	"flashargs=run setpart; setenv bootargs $bootargs "	\
+		"root=/dev/mtdblock$partition ro "		\
+		"rootfstype=jffs2\0"				\
 	"nboot=run nfsargs; bootp; tftp; bootm\0"		\
 	"fboot=run flashargs; fsload /boot/uImage; bootm\0"
 #endif

Dear Wolfgang,

here is patch which would make it compile. It allows to configure any size of malloc pool and any stack size. Patch is probably not ready for inclusion since I'm not certain if it is safe to use r1 register in abort handlers. If anyone knows, please comment patch.

Thanks in advance,
ladis

Index: cpu/arm925t/start.S
===================================================================
RCS file: /cvsroot/u-boot/u-boot/cpu/arm925t/start.S,v retrieving revision 1.9

diff -u -r1.9 start.S
@@ -83,6 +83,10 @@
 
 _TEXT_BASE:
 	.word	TEXT_BASE
+_STACK_OFS:
+	.word	CFG_MALLOC_LEN + CFG_GBL_DATA_SIZE
+_BAD_STACK_OFS:
+	.word	CFG_MALLOC_LEN + CFG_GBL_DATA_SIZE + CONFIG_STACKSIZE + 8
 
 .globl _armboot_start
 _armboot_start:

@@ -190,8 +194,8 @@
 	/* Set up the stack						    */
 stack_setup:
 	ldr	r0, _TEXT_BASE		/* upper 128 KiB: relocated uboot   */
-	sub	r0, r0, #CFG_MALLOC_LEN	/* malloc area                      */
-	sub	r0, r0, #CFG_GBL_DATA_SIZE /* bdinfo                        */
+	ldr	r1, _STACK_OFS
+	sub	r0, r0, r1		/* malloc area and bdinfo           */
 #ifdef CONFIG_USE_IRQ
 	sub	r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ)
 #endif

@@ -295,8 +299,8 @@
 	stmia	sp, {r0 - r12}			@ Save user registers (now in svc mode) r0-r12
 
 	ldr	r2, _armboot_start
-	sub	r2, r2, #(CONFIG_STACKSIZE+CFG_MALLOC_LEN)
-	sub	r2, r2, #(CFG_GBL_DATA_SIZE+8)  @ set base 2 words into abort stack
+	ldr	r1, _BAD_STACK_OFS
+	sub     r2, r2, r1
 	ldmia	r2, {r2 - r3}                   @ get values for "aborted" pc and cpsr (into parm regs)
 	add	r0, sp, #S_FRAME_SIZE		@ grab pointer to old stack
 

@@ -328,8 +332,8 @@
 
 	.macro get_bad_stack
 	ldr	r13, _armboot_start		@ setup our mode stack
-	sub	r13, r13, #(CONFIG_STACKSIZE+CFG_MALLOC_LEN)
-	sub	r13, r13, #(CFG_GBL_DATA_SIZE+8) @ reserved a couple spots in abort stack
+	ldr     r1, _BAD_STACK_OFS
+	sub     r13, r13, r1
 
 	str	lr, [r13]			@ save caller lr in position 0 of saved stack
 	mrs	lr, spsr                        @ get the spsr

Dear Ladislav,

Ummm... can you explain why you have to configure a stack size at all? The memory map should be set such that the stack has all the available memory to grow, so if I see someeone configuring a "stack size" I feel there must be a fundamental problem in this code.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"To IBM, 'open' means there is a modicum  of  interoperability  among
some of their equipment."                            - Harv Masterson

Ummm... I wouldn't expect such question from principal U-Boot author :) To be honest I didn't verify all startup code carefuly and as far as I remember CONFIG_STACKSIZE was always there. I remember you told me that ARM port is a bit broken and should be fixed. I can try it if I ever find some time, but it would be very helpfull if you show me the path.

My patch only removes limitation for malloc pool size and stack size to be directly loadable to register as a constant. Now it is probably time to think about it a bit more...

Best regards,
ladis

My ARM experience is ... ummm... let's say limited.

I see.

Well, I think that U-Boot should not rely on a pre-configured RAM size, but automatically detect how much RAM there is on a system, relocate itself to the very end of the RAM, and then set up a memory map as described in the README:

[Top of RAM]:
[optional: protected RAM]
[optional: framebuffer]
U-Boot bss
U-Boot data
U-Boot text
Malloc Arena
Board Info Data and permanent copy of global data U-Boot stack (growing downward)
...
[Bottom of RAM]

About it - about what?

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The amount of time between slipping on the peel and  landing  on  the
pavement is precisely 1 bananosecond.

Same here. Still learning and hoping future products will be MIPS based :)

That is a bit problem. I do not know about any way how to detect memory configuration. You need to configure traffic controler to match your setup.

That's probably doable and I'll try to implement it this way, except that end of RAM address will have to be given in config file. Or does anyone knows any trick how to detect it?

About initialization code on ARMs

Best regards,
ladis

And where again is the CHANGELOG entry? :-(

Added.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Men don't talk peace unless they're ready to back it up with war.
	-- Col. Green, "The Savage Curtain", stardate 5906.4

I already checked in your previous patch. Please submit a patch against current top of CVS if it was wrong.

And please note: from now on, I will reject all your patches if you don't provide proper patches including a changelog entry.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If something is different, it's either better or worse,  and  usually
both.                                                    - Larry Wall