December 2006 - U-Boot

[U-Boot-Users] FileHawk handles saved searches via a useful feature it calls Active Folders.
by grotto 23 Dec '06

23 Dec '06

A major feature, for instance, will be full disk encrypting drives. Ideally, any and all data on the device would be protected against the possibility of it ending up in the wrong hands. The Snap Server will automatically request an IP address through DHCP, which should bring the unit online in most networks. Cross-platform solutions score higher. Given that nobody has talked about successfully building a 64bit plugin from source, I have to assume it's not as a simple as a recompile and source level changes are required. The more common applications I use what many people use. At the rear, a single gigabit Ethernet port connects the NAS to your network. This one, however, offers superior operating range and a simpler, more intuitive interface. Even after adding a bunch of RSS feeds, called Klips, KlipFolio takes up very little desktop space while still managing to be quite easy to interact with. So I guess I'm still looking. roadway map and have a means to be expanded or upgraded with new data, plus it had to support both an internal rechargeable battery and 12-volt car power. The book is more that a chronological account of his life. This is all uncharted territory for office phone. I quickly ruled out units with monochrome screens as too hard to read and further re-affirmed my need for a color display. Avidian decided to better leverage that time in Outlook by turning the personal information manager into a full-fledged sales CRM application. Disable block tag code. Physical design is generally superior. This one is too heavy. For Unix systems, you can add hosts for NFS support. While he agrees that progress has been made, he doesn't see that this will move the masses to Linux. "Linux should be considered by small businesses for hosted or managed services, but not for self-management," says Antonopoulos.

1 0

[U-Boot-Users] minus sign holistic
by place mat 22 Dec '06

22 Dec '06

1 0

[U-Boot-Users] you can come over and we can laugh as JD chases our cats around the apartment.
by Red Cross 22 Dec '06

22 Dec '06

it all sounds so basic, and like it should be automatic. After five centuries, he remains as popular and intriguing as ever. and rather than communicate his insecurities and fears about making that leap again, he sought out other ways to stroke his male ego. not to be all alarmist with you, but maybe you should go to the doctor. i figured if i was starting all over again, why not start there. Nicholas, or more commonly known as Santa Claus. If you see something wonderful, you confidently embrace it. i'm sure party due to the honeymoon of a new relationship, but we often took hours to say goodbye. What Tarot Card are You? and the sex, was amazing.

1 0

[U-Boot-Users] [PATCH] MPC8360EMDS: Avoid replicating CFG_CMD commands
by Jerry Van Baren 22 Dec '06

22 Dec '06

Hi Dave, This is a fairly simple patch that rearranges the command configuration so there are not four very similar lists of commands for the four configurations (with/without PCI, with/without CFG_RAMBOOT). I got tired of editing four sets of commands (or worse, editing the wrong set of commands). The patch creates a CONFIG_COMMANDS_COMMON with the common commands, a CONFIG_COMMANDS_PCI with the PCI-related commands (or 0), and CONFIG_COMMANDS_REMOVE with the commands that are removed for CFG_RAMBOOT operation (or ~0). Diff didn't produce a very readable patch. :-( The result of the patch is: #define CONFIG_COMMANDS_COMMON (CONFIG_CMD_DFL \ | CFG_CMD_ASKENV \ | CFG_CMD_DHCP \ | CFG_CMD_I2C \ | CFG_CMD_PING) #if defined(CONFIG_PCI) #define CONFIG_COMMANDS_PCI CFG_CMD_PCI #else #define CONFIG_COMMANDS_PCI 0ULL #endif #if defined(CFG_RAMBOOT) #define CONFIG_COMMANDS_REMOVE ~(CFG_CMD_ENV \ | CFG_CMD_LOADS) #else #define CONFIG_COMMANDS_REMOVE ~0ULL #endif #define CONFIG_COMMANDS ((CONFIG_COMMANDS_COMMON \ | CONFIG_COMMANDS_PCI) \ & CONFIG_COMMANDS_REMOVE) Best regards, gvb Refactor into base commands, commands that are added, and commands that are removed from the base commands so that the list does not have to be replicated n times. Also added the DHCP command. Signed-off-by: Jerry Van Baren <vanbaren(a)cideas.com> --- include/configs/MPC8360EMDS.h | 44 ++++++++++++++-------------------------- 1 files changed, 16 insertions(+), 28 deletions(-) diff --git a/include/configs/MPC8360EMDS.h b/include/configs/MPC8360EMDS.h index 8ad6551..f56e7ad 100644 --- a/include/configs/MPC8360EMDS.h +++ b/include/configs/MPC8360EMDS.h @@ -426,40 +426,28 @@ #define CONFIG_LOADS_ECHO 1 /* echo on for serial download */ #define CFG_LOADS_BAUD_CHANGE 1 /* allow baudrate change */ -#if defined(CFG_RAMBOOT) -#if defined(CONFIG_PCI) -#define CONFIG_COMMANDS ((CONFIG_CMD_DFL \ - | CFG_CMD_PING \ - | CFG_CMD_ASKENV \ - | CFG_CMD_PCI \ - | CFG_CMD_I2C) \ - & \ - ~(CFG_CMD_ENV \ - | CFG_CMD_LOADS)) -#else -#define CONFIG_COMMANDS ((CONFIG_CMD_DFL \ - | CFG_CMD_PING \ +#define CONFIG_COMMANDS_COMMON (CONFIG_CMD_DFL \ | CFG_CMD_ASKENV \ - | CFG_CMD_I2C) \ - & \ - ~(CFG_CMD_ENV \ - | CFG_CMD_LOADS)) -#endif -#else + | CFG_CMD_DHCP \ + | CFG_CMD_I2C \ + | CFG_CMD_PING) #if defined(CONFIG_PCI) -#define CONFIG_COMMANDS (CONFIG_CMD_DFL \ - | CFG_CMD_PCI \ - | CFG_CMD_PING \ - | CFG_CMD_ASKENV \ - | CFG_CMD_I2C) +#define CONFIG_COMMANDS_PCI CFG_CMD_PCI #else -#define CONFIG_COMMANDS (CONFIG_CMD_DFL \ - | CFG_CMD_PING \ - | CFG_CMD_ASKENV \ - | CFG_CMD_I2C ) +#define CONFIG_COMMANDS_PCI 0ULL #endif + +#if defined(CFG_RAMBOOT) +#define CONFIG_COMMANDS_REMOVE ~(CFG_CMD_ENV \ + | CFG_CMD_LOADS) +#else +#define CONFIG_COMMANDS_REMOVE ~0ULL #endif +#define CONFIG_COMMANDS ((CONFIG_COMMANDS_COMMON \ + | CONFIG_COMMANDS_PCI) \ + & CONFIG_COMMANDS_REMOVE) + #include <cmd_confdefs.h> #undef CONFIG_WATCHDOG /* watchdog disabled */ -- 1.4.4.1

1 0

[U-Boot-Users] One of my favorite pastimes is checking out the day spas.
by Newman N. Ellen 22 Dec '06

22 Dec '06

1 0

Re: [U-Boot-Users] fsload questions
by Charles Krinke 22 Dec '06

22 Dec '06

Dear Wolfgang: In Linux, the same flash mounts in the blink of an eye. That is less then 500ms. This is the reason that I have started focusing back on U-Boot as there seems to be some incompatibility. As said earlier, we are using kernel.orgs linux-2.6.17.11 kernel source. We are also using Montavista 85xx toolchain to compile both the Linux kernel and U-boot. In formatting the flash, we use the utility flash_eraseall with a -j option, like this from bash # flash_eraseall -j /dev/mtd0 # mount -t jffs2 /dev/mtdblock0 /mnt/flash1 Charles

1 0

Re: [U-Boot-Users] fsload questions
by Charles Krinke 22 Dec '06

22 Dec '06

-----Original Message----- From: wd(a)denx.de [mailto:wd@denx.de] Sent: Thursday, December 21, 2006 4:40 PM To: Charles Krinke Cc: u-boot-users(a)lists.sourceforge.net Subject: Re: [U-Boot-Users] fsload questions In message <A590D28B5042C041BCC880094CB6172E33DF48(a)mail1irv.inside.istor.com> you wrote: > > We are using the MTD code in the released u-boot-1.1.6 tarball and it > does compile cleanly and runs ls, fsinfo and fsload, albeit there is a > two minute delay whenever it runs. Which MTD code are you using in your Linux kernel and for the tools you use to format the file system? How long does mounting the file system take under Linux? > I am very puzzled why you are avoiding loading a Linux kernel image from > a JFFS2 file system. Is there some set of problems that are not obvious Because it's one of the slowest ways to boot a system. > that need to be addressed, or some incompatibility between U-Boot and > the MTD flash logic in Linux? No, it's just inherently slow. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Where people stand is not as important as which way they face. - Terry Pratchett & Stephen Briggs, _The Discworld Companion_ Dear Wolfgang: We are using Linux-2.6.17.11 with the MTD support provided in the released kernel from kernel.org with no modifications. Is this potentially a part of the problem? I am somewhat puzzled by the fact that the Linux kernel writes files from the top towards the bottom and U-Boot tries to read files from the bottom towards the top. Is this potentially the reason for U-Boot's slowness in reading a NAND/JFFS2 file system? Charles

1 0

Re: [U-Boot-Users] fsload questions
by Charles Krinke 22 Dec '06

22 Dec '06

Dear Wolfgang: Our file system is a single Toshiba 256Mb NAND flash which has one partition defined at the beginning (lowest address). It is a 16Mbyte flash partition consisting of a single file currently, which is uImage. There should be no fragmentation at all as the flash was formatted with 'flash_eraseall -j', then the kernel image was copied to it. No other writes, rm's or copies were done. of 16Mbytes in size. Best regards, We are using the MTD code in the released u-boot-1.1.6 tarball and it does compile cleanly and runs ls, fsinfo and fsload, albeit there is a two minute delay whenever it runs. I am very puzzled why you are avoiding loading a Linux kernel image from a JFFS2 file system. Is there some set of problems that are not obvious that need to be addressed, or some incompatibility between U-Boot and the MTD flash logic in Linux? I have enabled debugging and I can see that the scanning of the jffs2 starts at the bottom (lowest address) and works its way up. I also enabled debugging in the Linux kernel and can see that it starts at the top (highest address) and works its way towards the bottom. It is beginning to appear the time is spent mostly in U-boot working its way from the bottom of the flash to the top of the flash to find the file system one block at a time, which is what appears to be taking the two minutes. Perhaps you could comment on this. Charles

2 1

Re: [U-Boot-Users] fsload questions
by Charles Krinke 22 Dec '06

22 Dec '06

In message <A590D28B5042C041BCC880094CB6172E33DF45(a)mail1irv.inside.istor.com> you wrote: > > But it takes almost 2 minutes to scan the flash before the fsload > completes and loads the uImage. So, this adds an additional 2 minutes to How big is your file system, and how heavily fragmented might it be (how long have you been using it, especially appending to existing files?). And which version of the MTD code are you using? Charles comment to Wolfgang's comment: It is a 16Mbyte flash partition consisting of a single file currently, which is uImage. There should be no fragmentation at all as the flash was formatted with 'flash_eraseall -j', then the kernel image was copied to it. No other writes, rm's or copies were done. The issue becomes the customer desiring to have one root file system partition containing the uImage kernel and the contents of /bin, /sbin and the like. The single kernel file is just to test fsload. > the boot of the embedded system, which is clearly a problem. Indeed. This is why I try to avoid loading a Linux kernel image from a JFFS2 file system (not to mention the fact that it makes little sense to compress and already compressed image - it just adds to the delay). Charles comment to Wolfgang's comment: So, would this mean that you would not expect U-Boot to do an fsload from a flash formatted with flash_eraseall in a timely fashion. Perhaps there is some inconsistency between the formatting of the flash in Linux and the reading of the flash in U-boot? > The flash was formatted in Linux using the flash_eraseall utility. I am > hoping that you, or someone else, can tell me that there is some > configuration constant missing or that the flash may be formatted in a > way that is not quite consistent with U-Boot's needs. There are a lot of potential causes. Enable debugging and check what's taking so much time... Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Our universe is a fragile house of atoms, held together by the mortar of cause-and-effect. One magician would be two too many. - Terry Pratchett, _The Dark Side of the Sun_

3 2

Re: [U-Boot-Users] fsload questions
by Charles Krinke 22 Dec '06

22 Dec '06

-----Original Message----- From: Stefan Roese [mailto:sr@denx.de] Sent: Thursday, December 21, 2006 11:18 AM To: u-boot-users(a)lists.sourceforge.net Cc: Charles Krinke; Randy Brown; Kevin Smith Subject: Re: [U-Boot-Users] fsload questions On Thursday 21 December 2006 19:47, Charles Krinke wrote: > I8000E> bootm 100000 > ## Booting image at 00100000 ... > Image Name: Linux-2.6.17.11 > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size: 936926 Bytes = 915 kB > Load Address: 00000000 > Entry Point: 00000000 > Verifying Checksum ... OK > Uncompressing Kernel Image ... Error: inflate() returned -3 > GUNZIP ERROR - must RESET board to recover Use a bigger address (e.g. 0x400000) since the uncompressing can overwrite the original image. Best regards, Stefan Thank you Stefan, that cleared up one mystery. Given an offset of 0x1000000 instead of 0x100000, uImage can be loaded by fsload and will now bootm to a bash prompt. This leaves the time question. It seems that the fsload starts out saying Scanning JFFS2 FS But it takes almost 2 minutes to scan the flash before the fsload completes and loads the uImage. So, this adds an additional 2 minutes to the boot of the embedded system, which is clearly a problem. The flash was formatted in Linux using the flash_eraseall utility. I am hoping that you, or someone else, can tell me that there is some configuration constant missing or that the flash may be formatted in a way that is not quite consistent with U-Boot's needs. Charles

2 1