[U-Boot-Users] mtdparts

[U-Boot-Users] mtdparts

[Ladislav Michl]

Hi there.

I'm just trying to sync with U-Boot development and found a little
regresion in new mtdparts code. Previously I was using custom partition
function, which let me do precisely what I wanted.

mtd0 - U-Boot
mtd1 - env
mtd2 - r_env
mtd3 - rootfs0
mtd4 - rootfs1
... etc

In above scheme my custom part function allowed only chpart [34], so it
was not even possible to change partition to evn sector for example.
Moreover it was pretty easy to construct kernel command line this way:
setenv bootargs '$bootargs root=/dev/mtdblock$partition ro rootfstype=jffs2'
And everything worked nicely. That is no longer case and it's real pain
with both NOR and NAND devices used in system.

Prefered solution for me is to fix kernel to be able to mount root
filesystem from MTD device given by name (root=mtd:rootfs0) unless
someone has better idea :-). Something which would work also with 2.4
kernels would be appreciated.

	ladis

[U-Boot-Users] mtdparts

[Wolfgang Denk]

In message <20050906180248.GA5160@orphique> you wrote:
> 
> In above scheme my custom part function allowed only chpart [34], so it
> was not even possible to change partition to evn sector for example.

Ummm... I can understand what you mean, but this is  not  how  things
normally  are  done  in a UNIX environment. It seems a very arbitrary
restriction to me, which I wouldn;t like if I was working on  such  a
system.

> Moreover it was pretty easy to construct kernel command line this way:
> setenv bootargs '$bootargs root=/dev/mtdblock$partition ro rootfstype=jffs2'

What prevents you from doing the same now?


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
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it  on
the computer.

[U-Boot-Users] mtdparts

[Ladislav Michl]

On Tue, Sep 06, 2005 at 09:47:08PM +0200, Wolfgang Denk wrote:
> > In above scheme my custom part function allowed only chpart [34], so it
> > was not even possible to change partition to evn sector for example.
> 
> Ummm... I can understand what you mean, but this is  not  how  things
> normally  are  done  in a UNIX environment. It seems a very arbitrary
> restriction to me, which I wouldn;t like if I was working on  such  a
> system.

Ack. I have no strong requirement for such feature.

> > Moreover it was pretty easy to construct kernel command line this way:
> > setenv bootargs '$bootargs root=/dev/mtdblock$partition ro rootfstype=jffs2'
> 
> What prevents you from doing the same now?

Previously I did it in environment:

if test -n $swapos; then
	if test $ospart -eq 0; then chpart 4; else chpart 3; fi;
	setenv swapos; saveenv;
else
	if test $ospart -eq 0; then chpart 3; else chpart 4; fi;
fi
flashargs=run setpart; fixroot; setenv bootargs $bootargs \
	root=/dev/mtdblock$partition ro rootfstype=jffs2
fboot=run flashargs;fsload;bootm

This no longer possible, because $partiton is nand0,1 now, so finding
corresponding Linux device is more tricky. For now I solved it in C by
writing new command which does the trick. Hush doesn't support 'eval'
nor something like echo $fs`echo $ospart` where fs0=/dev/mtdblock3
and fs1=/dev/mtdblock4, so it's hard to do it using builtin commands.
In case I'm the only one who needs something like this, I'm perfectly
fine with my current solution.

Best regards,
	ladis

[U-Boot-Users] mtdparts

[Wolfgang Denk]

In message <20050907082946.GA19256@orphique> you wrote:
>
> Previously I did it in environment:
...
> flashargs=run setpart; fixroot; setenv bootargs $bootargs \
> 	root=/dev/mtdblock$partition ro rootfstype=jffs2
...
> 
> This no longer possible, because $partiton is nand0,1 now, so finding
> corresponding Linux device is more tricky. For now I solved it in C by

I see.

> In case I'm the only one who needs something like this, I'm perfectly
> fine with my current solution.

You made a point. Please allow for a little time to think  about  it.
Send me a reminder in a week or so in case I don;t send a followup.

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
Keep your eyes wide open before marriage, half shut afterwards.
                                                 -- Benjamin Franklin

[U-Boot-Users] Does anyone use Lan91c96 in U-Boot?

[Bryan Wu]

Hi folks:

I use lan91c96 ethernet controller in my system board. And the Lan91c96 connects to my SoC by M68K bus.
Now I modified the original code to support the chip in U-Boot, U-Boot can download the kernel from networks by tftp.
But sometimes the kernel data is ok, sometimes the kernel data CRC error when I use bootm to bootup the kernel.

In the CRC error situation, U-Boot must think the kernel data downloaded from networks to RAM is ok, but the kernel decompressor
said it is CRC error.

Is there any idea for this? How to debug this?

Thanks a lot
Best Regards
Bryan Wu from China

[U-Boot-Users] mtdparts

[Andreas Engel]

On Wed, 7 Sep 2005 10:29:46 +0200 Ladislav Michl wrote:

> [...]

>flashargs=run setpart; fixroot; setenv bootargs $bootargs \
>	root=/dev/mtdblock$partition ro rootfstype=jffs2
>fboot=run flashargs;fsload;bootm

> [...]
>
>In case I'm the only one who needs something like this, I'm perfectly
>fine with my current solution.

You're not the only one. I'm using a nearly identical approach here.

Regards,
  Andreas

[U-Boot-Users] mtdparts

[Wolfgang Denk]

In message <20050907123053.0000449b@idefix> you wrote:
>
> >In case I'm the only one who needs something like this, I'm perfectly
> >fine with my current solution.
> 
> You're not the only one. I'm using a nearly identical approach here.

We willprovide an extension soon; we're going to create an additional
variable 'mtddevnum'.

Note: the numbering will be exactly as partitions are listed  in  the
$mtdparts  variable.  This  way  user  can fully control the indexing
sequence but it is also a bit more troublesome you have to take  care
about the order of devices in $mtdparts.

But the greater flexibilty seems to me to be a big advantage over any
fixed scheme which cannot know about the init sequence in  the  Linux
kernel.

Is this OK with you?

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
"Nature is very un-American.  Nature never hurries."
- William George Jordan

[U-Boot-Users] mtdparts

[Ladislav Michl]

On Wed, Sep 07, 2005 at 02:54:59PM +0200, Wolfgang Denk wrote:
> We willprovide an extension soon; we're going to create an additional
> variable 'mtddevnum'.
> 
> Note: the numbering will be exactly as partitions are listed  in  the
> $mtdparts  variable.  This  way  user  can fully control the indexing
> sequence but it is also a bit more troublesome you have to take  care
> about the order of devices in $mtdparts.
> 
> But the greater flexibilty seems to me to be a big advantage over any
> fixed scheme which cannot know about the init sequence in  the  Linux
> kernel.
> 
> Is this OK with you?

Wolfgang,

that sounds perfectly right to me. Note that once Linux kernel gets
capability of mounting rootfs by mtd(part) name, it might be usefull to
add yet another variable mtddevname.

Currently you can do something like:
mount -t jffs2 mtd:fs1 /mount_point

I hope kernel will get support for mounting rootfs by name soon.

Best regards,
	ladis

[U-Boot-Users] mtdparts

[Wolfgang Denk]

Dear Ladislav,

in message <20050907133705.GA22895@orphique> you wrote:
>
> > We willprovide an extension soon; we're going to create an additional
> > variable 'mtddevnum'.

Done.

> that sounds perfectly right to me. Note that once Linux kernel gets
> capability of mounting rootfs by mtd(part) name, it might be usefull to
> add yet another variable mtddevname.

Done, too.

Just checked in. Please let me know if this works for you.

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
grep me no patterns and I'll tell you no lines.

[U-Boot-Users] mtdparts

[Ladislav Michl]

Wolfgang,

On Tue, Sep 13, 2005 at 12:25:51AM +0200, Wolfgang Denk wrote:
> > > We willprovide an extension soon; we're going to create an additional
> > > variable 'mtddevnum'.
[snip]
> Just checked in. Please let me know if this works for you.

Works nicely, thanks a lot! Tested on board VoiceBlue and NetStar. Btw,
last commit to U-Boot's git repository is 10 days old. Am I supposed to
generate patch against CVS?

Best regards,
	ladis

[PATCH] voiceblue update (Re: [U-Boot-Users] mtdparts)

[Ladislav Michl]

On Tue, Sep 13, 2005 at 05:00:17PM +0200, Ladislav Michl wrote:
> Wolfgang,
> 
> On Tue, Sep 13, 2005 at 12:25:51AM +0200, Wolfgang Denk wrote:
> > > > We willprovide an extension soon; we're going to create an additional
> > > > variable 'mtddevnum'.
> [snip]
> > Just checked in. Please let me know if this works for you.
> 
> Works nicely, thanks a lot! Tested on board VoiceBlue and NetStar. Btw,
> last commit to U-Boot's git repository is 10 days old. Am I supposed to
> generate patch against CVS?

Git repository seems to be updated, thanks :-)

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>

CHANGELOG
* VoiceBlue update: use new MTD flash partitioning methods, use more
  reasonable TEXT_BASE, update default environment and enable keyed
  autoboot.
    
diff --git a/board/voiceblue/config.mk b/board/voiceblue/config.mk
--- a/board/voiceblue/config.mk
+++ b/board/voiceblue/config.mk
@@ -12,5 +12,5 @@ ifeq ($(VOICEBLUE_SMALL_FLASH),y)
 TEXT_BASE = 0x20012000
 else
 # Running in SDRAM...
-TEXT_BASE = 0x13000000
+TEXT_BASE = 0x13FD0000
 endif
diff --git a/board/voiceblue/voiceblue.c b/board/voiceblue/voiceblue.c
--- a/board/voiceblue/voiceblue.c
+++ b/board/voiceblue/voiceblue.c
@@ -43,8 +43,8 @@ int dram_init(void)
 
 	*((volatile unsigned short *) VOICEBLUE_LED_REG) = 0xff;
 
- 	/* Take the Ethernet controller out of reset and wait
- 	 * for the EEPROM load to complete. */
+	/* Take the Ethernet controller out of reset and wait
+	 * for the EEPROM load to complete. */
 	*((volatile unsigned short *) GPIO_DATA_OUTPUT_REG) |= 0x80;
 	udelay(10);	/* doesn't work before interrupt_init call */
 	*((volatile unsigned short *) GPIO_DATA_OUTPUT_REG) &= ~0x80;
diff --git a/include/configs/voiceblue.h b/include/configs/voiceblue.h
--- a/include/configs/voiceblue.h
+++ b/include/configs/voiceblue.h
@@ -47,6 +47,8 @@
 #define CONFIG_SETUP_MEMORY_TAGS	1
 #define CONFIG_INITRD_TAG		1
 
+#define CONFIG_VERSION_VARIABLE	1       /* include version env variable */
+
 /*
  * Physical Memory Map
  */
@@ -94,7 +96,6 @@
 
 #define CONFIG_ENV_OVERWRITE
 
-#define CFG_JFFS_CUSTOM_PART	/* see board/voiceblue/jffs2parts.c */
 #endif
 
 /*
@@ -104,9 +105,11 @@
 #ifdef VOICEBLUE_SMALL_FLASH
 #define CFG_MALLOC_LEN		(SZ_64K - CFG_GBL_DATA_SIZE)
 #define CONFIG_STACKSIZE	SZ_8K
+#define PHYS_SDRAM_1_RESERVED	0
 #else
 #define CFG_MALLOC_LEN		SZ_4M
 #define CONFIG_STACKSIZE	SZ_1M
+#define PHYS_SDRAM_1_RESERVED	(CFG_MONITOR_LEN + CFG_MALLOC_LEN + CONFIG_STACKSIZE)
 #endif
 
 /*
@@ -174,26 +177,49 @@
 #define CONFIG_BOOTCOMMAND	"run nboot"
 #define CONFIG_PREBOOT		"run setup"
 #define	CONFIG_EXTRA_ENV_SETTINGS				\
+	"silent=1\0"						\
 	"ospart=0\0"						\
 	"swapos=no\0"						\
 	"setpart="						\
 	"if test $swapos = yes; then "				\
-		"if test $ospart -eq 0; then chpart 4; else chpart 3; fi; "\
+		"if test $ospart -eq 0; then chpart nor0,4; else chpart nor0,3; fi; "\
 		"setenv swapos no; saveenv; "			\
 	"else "							\
-		"if test $ospart -eq 0; then chpart 3; else chpart 4; fi; "\
+		"if test $ospart -eq 0; then chpart nor0,3; else chpart nor0,4; fi; "\
 	"fi\0"							\
 	"setup=setenv bootargs console=ttyS0,$baudrate "	\
-		"mtdparts=$mtdparts\0"				\
-	"nfsargs=run setpart; setenv bootargs $bootargs "	\
-		"root=/dev/nfs ip=dhcp\0"			\
+		"$mtdparts\0"					\
+	"nfsargs=setenv bootargs $bootargs "			\
+		"ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname::off " \
+		"nfsroot=$serverip:$rootpath root=/dev/nfs\0"	\
 	"flashargs=run setpart; setenv bootargs $bootargs "	\
-		"root=/dev/mtdblock$partition ro "		\
+		"root=/dev/mtdblock$mtddevnum ro "		\
 		"rootfstype=jffs2\0"				\
-	"nboot=run nfsargs; bootp; tftp; bootm\0"		\
-	"fboot=run flashargs; fsload /boot/uImage; bootm\0"
+	"initrdargs=setenv bootargs $bootargs "			\
+		"ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname::off\0" \
+	"fboot=run flashargs; fsload /boot/uImage; bootm\0"	\
+	"iboot=bootp; run initrdargs; tftp; bootm\0"		\
+	"nboot=bootp; run nfsargs; tftp; bootm\0"
 #endif
 
+#ifndef VOICEBLUE_SMALL_FLASH
+#define CONFIG_SILENT_CONSOLE		1	/* enable silent startup */
+
+#if 1	/* feel free to disable for development */
+#define CONFIG_AUTOBOOT_KEYED		/* Enable password protection	*/
+#define CONFIG_AUTOBOOT_PROMPT	"\nVoiceBlue Enterprise - booting...\n"
+#define CONFIG_AUTOBOOT_DELAY_STR	"."	/* 1st "password"	*/
+#endif
+
+/*
+ * JFFS2 partitions (mtdparts command line support)
+ */
+#define CONFIG_JFFS2_CMDLINE
+#define MTDIDS_DEFAULT		"nor0=omapflash.0"
+#define MTDPARTS_DEFAULT	"mtdparts=omapflash.0:128k(uboot),64k(env),64k(r_env),16256k(data1),-(data2)"
+
+#endif	/* VOICEBLUE_SMALL_FLASH */
+
 /* this must be included AFTER the definition of CONFIG_COMMANDS (if any) */
 #include <cmd_confdefs.h>
 
@@ -213,7 +239,7 @@
 #define CFG_BARGSIZE		CFG_CBSIZE	/* Boot Argument Buffer Size	*/
 
 #define CFG_MEMTEST_START	PHYS_SDRAM_1
-#define CFG_MEMTEST_END		PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE
+#define CFG_MEMTEST_END		PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE - PHYS_SDRAM_1_RESERVED
 
 #undef	CFG_CLKS_IN_HZ		/* everything, incl board info, in Hz */
 
@@ -247,22 +273,4 @@
 
 #define VOICEBLUE_LED_REG	0x04030000
 
-/*
- * JFFS2 partitions
- *
- */
-/* No command line, one static partition */
-#undef CONFIG_JFFS2_CMDLINE
-#define CONFIG_JFFS2_DEV		"nor0"
-#define CONFIG_JFFS2_PART_SIZE		0xFFFFFFFF
-#define CONFIG_JFFS2_PART_OFFSET	0x00040000
-
-/* mtdparts command line support */
-/* Note: fake mtd_id used, no linux mtd map file */
-/*
-#define CONFIG_JFFS2_CMDLINE
-#define MTDIDS_DEFAULT		"nor0=voiceblue-0"
-#define MTDPARTS_DEFAULT	"mtdparts=voiceblue-0:128k(uboot),64k(env),64k(renv),-(jffs2)"
-*/
-
 #endif	/* __CONFIG_H */

[U-Boot-Users] [PATCH] voiceblue update (Re: mtdparts)

[Wolfgang Denk]

In message <20050915084918.GB8576@orphique> you wrote:
>
> * VoiceBlue update: use new MTD flash partitioning methods, use more
>   reasonable TEXT_BASE, update default environment and enable keyed
>   autoboot.

Sorry, this does not apply cleanly (any more). Can you  please  check
and re-submit those parts that are still needed? Thanks.

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
Let the programmers be many and the managers few -- then all will  be
productive.               -- Geoffrey James, "The Tao of Programming"

[U-Boot-Users] [PATCH] voiceblue update (Re: mtdparts)

[Ladislav Michl]

On Sat, Jul 22, 2006 at 09:05:07PM +0200, Wolfgang Denk wrote:
> In message <20050915084918.GB8576@orphique> you wrote:
> >
> > * VoiceBlue update: use new MTD flash partitioning methods, use more
> >   reasonable TEXT_BASE, update default environment and enable keyed
> >   autoboot.
> 
> Sorry, this does not apply cleanly (any more). Can you  please  check
> and re-submit those parts that are still needed? Thanks.

Hi Wolfgang,

most of this patch went already in. Only minor part (done here also for
NetStar board) is missing, which could be found in following patch,
which also does minor whitespace cleanup.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>

CHANGELOG
* Use MACH_TYPE_NETSTAR and MACH_TYPE_VOICEBLUE defines instead of
  numbers in code.


diff --git a/board/netstar/netstar.c b/board/netstar/netstar.c
index d6b620c..f52afe5 100644
--- a/board/netstar/netstar.c
+++ b/board/netstar/netstar.c
@@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
 int board_init(void)
 {
 	/* arch number of NetStar board */
-	gd->bd->bi_arch_number = 692;
+	gd->bd->bi_arch_number = MACH_TYPE_NETSTAR;
 
 	/* adress of boot parameters */
 	gd->bd->bi_boot_params = 0x10000100;
diff --git a/board/voiceblue/voiceblue.c b/board/voiceblue/voiceblue.c
index 04093d1..c8dde36 100644
--- a/board/voiceblue/voiceblue.c
+++ b/board/voiceblue/voiceblue.c
@@ -28,8 +28,7 @@ int board_init(void)
 	*((volatile unsigned char *) VOICEBLUE_LED_REG) = 0xaa;
 
 	/* arch number of VoiceBlue board */
-	/* TODO: use define from asm/mach-types.h */
-	gd->bd->bi_arch_number = 218;
+	gd->bd->bi_arch_number = MACH_TYPE_VOICEBLUE;
 
 	/* adress of boot parameters */
 	gd->bd->bi_boot_params = 0x10000100;
@@ -41,8 +40,8 @@ int dram_init(void)
 {
 	*((volatile unsigned short *) VOICEBLUE_LED_REG) = 0xff;
 
- 	/* Take the Ethernet controller out of reset and wait
- 	 * for the EEPROM load to complete. */
+	/* Take the Ethernet controller out of reset and wait
+	 * for the EEPROM load to complete. */
 	*((volatile unsigned short *) GPIO_DATA_OUTPUT_REG) |= 0x80;
 	udelay(10);	/* doesn't work before interrupt_init call */
 	*((volatile unsigned short *) GPIO_DATA_OUTPUT_REG) &= ~0x80;

[U-Boot-Users] [PATCH] voiceblue update (Re: mtdparts)

[Stefan Roese]

Hi Ladis,

On Tuesday 25 July 2006 17:00, Ladislav Michl wrote:
> most of this patch went already in. Only minor part (done here also for
> NetStar board) is missing, which could be found in following patch,
> which also does minor whitespace cleanup.

Applied. Thanks.

Best regards,
Stefan

[U-Boot-Users] mtdparts

[Andreas Engel]

On Wed, 7 Sep 2005 14:54:59 +0200 Wolfgang Denk wrote:

>We willprovide an extension soon; we're going to create an additional
>variable 'mtddevnum'.
>
>Note: the numbering will be exactly as partitions are listed  in  the
>$mtdparts  variable.  This  way  user  can fully control the indexing
>sequence but it is also a bit more troublesome you have to take  care
>about the order of devices in $mtdparts.
>
>But the greater flexibilty seems to me to be a big advantage over any
>fixed scheme which cannot know about the init sequence in  the  Linux
>kernel.
>
>Is this OK with you?

That's ok with me, too. We won't change our current implementation anyway.

Regards,
  Andreas Engel