Re: [U-Boot] Disable features
Hi, Ben, Ben Warren wrote: > Do you have CONFIG_RESET_PHY_R defined? It forces a call to eth_init(), > which most likely causes the delay you're seeing. Try commenting it out > in your config file. Yes, CONFIG_RESET_PHY_R is defined by default. And I can see it linking to the eth_init and then macb_init which results in the auto-negotiation. I am going to comment it out and test it. But what is the use for this config? Why does ATMEL define it in many of their boards? Thanks, Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Disable features
Wolfgang Denk wrote: > Dear Derek Ou, > > In message <49fa1279.5080...@siconix.com> you wrote: > >> When we have the Network support compiled, it takes a few second to do >> the auto-negotiation >> > That should be part of the network init sequence, which should only be > run when you run a network command. > The board goes to auto-negotiation before boot delay count down. So it's before I can run any command. I will look into the network init routine then. >> even though MAC chip is not on board. Then it fails out and goes to >> autoboot. Is it a board specific problem or system problem? >> > Board (or architecture) problem. > Which board / architecture is this? > It's an Atmel AT91SAM9263(ek) board. ARM architecture. > Best regards, > Wolfgang Denk > Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Disable features
Wolfgang Denk wrote: > Why would compiled in Network support slow down the boot process? > > The network interface will only be initialized as soon as you use it. > If you don't have one, then you probably will not try using it - then > why would it delay your boot? > When we have the Network support compiled, it takes a few second to do the auto-negotiation even though MAC chip is not on board. Then it fails out and goes to autoboot. Is it a board specific problem or system problem? Thanks, Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Disable features
Hi, > Is existing a way to globally disable some features such as ethernet > or Nand support, instead of doing it for a specific board? > Other than recompiling, is it possible to disable Ethernet through environment settings? At our work, we often need Ethernet only during development, manufacturing and troubleshooting. So we put the Ethernet chip on the test fixture instead of the final board. However, compiling in Ethernet slow down the booting process. So it will be great if Ethernet can be disabled and enabled by flipping an environment setting. Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91: NAND OOB and ECC in U-Boot vs Linux (Jesus Alvarez)
Dear Jesus Alvarez > The AT91 Linux kernel patches for versions 2.6.27 or later use a separate > atmel_nand.c driver that implements some OOB and ECC options that are not > exactly the same as those in the standard kernel NAND driver (nand_base.c , > etc.). AT91 based boards can use the CONFIG_MTD_NAND_ATMEL option to enable > the atmel_nand driver together with CONFIG_MTD_NAND_ATMEL_ECC_HW, > CONFIG_MTD_NAND_ATMEL_ECC_SOFT or CONFIG_MTD_NAND_ATMEL_ECC_NONE for the > desired ECC. The OOB layout used by that driver appears to be different. > I have no problem using kernel 2.6.27 and u-boot (1.3.4 and 2009.01) on my at91sam9263ek. The Linux kernel driver uses ECC_HW by default and it does not work with U-boot. As long as I set the kernel driver to use ECC_SOFT, Linux kernel loads the root file system (written by U-boot) and detects bad blocks correctly. And I think the ECC_HW is not implemented in U-boot at91 driver. At least in version 1.3.4, the at91 nand driver just points ECC_HW back to ECC_SOFT instead of using the at91 ECC hardware module. > Could this create the potential for incompatibilities when a NAND filesystem > is created by U-Boot for mounting from a Linux kernel using the atmel_nand > driver? Are there any kernel config options to avoid to make filesystems > initialized with the U-Boot "nand write.jffs2" command fully compatible with > the kernel MTD NAND drivers nand write.jffs2 just means skipping bad blocks when writing to NAND. You should always use it. Without ".jffs2", you will write data to bad blocks. Actually after ver 1.3.4, jffs2 is no longer necessary for "nand write" and bad blocks will be skipped by default. Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Pad data length for nand write
Currently, the nand_util.c does not manipulate NAND flash page by page. It's the nand_base.c provides that level of NAND control. Implementing this properly requires changes to the existing structure. Also, adding "+length" syntax means command interface change as well. Since it's not to the interest of my company to implement new feature instead of maintaining existing behavior, I will not look into this in my working hours then. So everybody is welcomed to work on this issue and submit your patches. I'd love to see them. By the way, I think WATCHDOG_RESET() should be added to nand_do_write_opts() and nand_do_read_opts() at nand_base.c. Please include it if you have patch for the above implementation. Derek Scott Wood wrote: > You can define a static array for holding one page, as v1.3.4 did. > The space after the caller's buffer is *not* a safe location. >> Maybe we should implement, like Wolfgang said, a "+length" syntax in >> the "nand write" >> command to indicates "round up to the next page boundary". > Sounds good. If we do that, we should do similarly with "nand erase". > It currently (sometimes) warns and rounds up if you give it a > non-block-aligned size. >> In this case, do_nand() >> can assume that it's safe to write pass memory address (add + length) >> and Flash offset >> (off + length). > No, it will *not* assume that it's safe to write to any memory of the > caller's. It will allocate its own buffer. > > -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Pad data length for nand write
This routine is copied from nand_write_opts() at nand_util.c of v1.3.4. It maybe better to pad data length and data buffer in do_nand() at cmd_nand.c. But I don't see real difference. I didn't allocate a new buffer since the data length is defined in the command arguments and I have no knowledge of a safe location and large enough memory space to store data. Maybe we should implement, like Wolfgang said, a "+length" syntax in the "nand write" command to indicates "round up to the next page boundary". In this case, do_nand() can assume that it's safe to write pass memory address (add + length) and Flash offset (off + length). Derek Scott Wood wrote: > On Tue, Feb 17, 2009 at 10:15:07AM -0700, Derek Ou wrote: > >> +/* now, pad data with 0xff */ >> +if (page_offset != 0) >> +memset(buffer + *length, 0xff, pad_len); >> > You cannot write to the caller's buffer (or worse, past the end of the > caller's buffer) like this. You'll need to allocate a new, padded > buffer. > > -Scott > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Pad data length for nand write
Sorry that my patch went out twice. I ran into smtp authentication issue with git-send-email. Also, what is the right way to add more comments to a patch? Should I edit the patch generated by git-format-patch or I should just add commit title, blank line and the full commit message when I git commit my change locally. Anyway, here is the purpose of the patch. Until v1.3.4, "nand write.jffs2" supports non page-aligned data write and pad data automatically to page alignment. As a result, we can use the following scripts to automate downloading a file and writing it to flash. "tftp file.bin" and "nand write.jffs2 add_# off_# $(filesize)" But in the later releases, this feature was no longer supported. So my patch restores this feature to nand write command. Derek Mike Frysinger wrote: > On Tuesday 17 February 2009 12:15:06 Derek Ou wrote: > >> Signed-off-by: Derek Ou >> > could you document what this is actually for ? > -mike > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Pad data length for nand write
Signed-off-by: Derek Ou
---
drivers/mtd/nand/nand_util.c | 25 ++---
1 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 6ba52b3..b9d292a 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -475,25 +475,36 @@ int nand_write_skip_bad(nand_info_t *nand, size_t offset,
size_t *length,
{
int rval;
size_t left_to_write = *length;
+ size_t page_offset, pad_len = 0;
size_t len_incl_bad;
u_char *p_buffer = buffer;
- /* Reject writes, which are not page aligned */
- if ((offset & (nand->writesize - 1)) != 0 ||
- (*length & (nand->writesize - 1)) != 0) {
- printf ("Attempt to write non page aligned data\n");
+ /* Reject writes when offset is not page aligned */
+ if ((offset & (nand->writesize - 1)) != 0 ) {
+ printf ("Attempt to write address non page aligned\n");
return -EINVAL;
}
- len_incl_bad = get_len_incl_bad (nand, offset, *length);
+ /* Pad write length if it's not page aligned */
+ page_offset = left_to_write & (nand->writesize - 1);
+ if (page_offset != 0) {
+ pad_len = nand->writesize - page_offset;
+ left_to_write += pad_len;
+ }
+
+ len_incl_bad = get_len_incl_bad (nand, offset, left_to_write);
if ((offset + len_incl_bad) >= nand->size) {
printf ("Attempt to write outside the flash area\n");
return -EINVAL;
}
- if (len_incl_bad == *length) {
- rval = nand_write (nand, offset, length, buffer);
+ /* now, pad data with 0xff */
+ if (page_offset != 0)
+ memset(buffer + *length, 0xff, pad_len);
+
+ if (len_incl_bad == left_to_write) {
+ rval = nand_write (nand, offset, &left_to_write, buffer);
if (rval != 0)
printf ("NAND write to offset %zx failed %d\n",
offset, rval);
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Pad data length for nand write
Signed-off-by: Derek Ou
---
drivers/mtd/nand/nand_util.c | 25 ++---
1 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 6ba52b3..b9d292a 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -475,25 +475,36 @@ int nand_write_skip_bad(nand_info_t *nand, size_t offset,
size_t *length,
{
int rval;
size_t left_to_write = *length;
+ size_t page_offset, pad_len = 0;
size_t len_incl_bad;
u_char *p_buffer = buffer;
- /* Reject writes, which are not page aligned */
- if ((offset & (nand->writesize - 1)) != 0 ||
- (*length & (nand->writesize - 1)) != 0) {
- printf ("Attempt to write non page aligned data\n");
+ /* Reject writes when offset is not page aligned */
+ if ((offset & (nand->writesize - 1)) != 0 ) {
+ printf ("Attempt to write address non page aligned\n");
return -EINVAL;
}
- len_incl_bad = get_len_incl_bad (nand, offset, *length);
+ /* Pad write length if it's not page aligned */
+ page_offset = left_to_write & (nand->writesize - 1);
+ if (page_offset != 0) {
+ pad_len = nand->writesize - page_offset;
+ left_to_write += pad_len;
+ }
+
+ len_incl_bad = get_len_incl_bad (nand, offset, left_to_write);
if ((offset + len_incl_bad) >= nand->size) {
printf ("Attempt to write outside the flash area\n");
return -EINVAL;
}
- if (len_incl_bad == *length) {
- rval = nand_write (nand, offset, length, buffer);
+ /* now, pad data with 0xff */
+ if (page_offset != 0)
+ memset(buffer + *length, 0xff, pad_len);
+
+ if (len_incl_bad == left_to_write) {
+ rval = nand_write (nand, offset, &left_to_write, buffer);
if (rval != 0)
printf ("NAND write to offset %zx failed %d\n",
offset, rval);
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NAND issues
I have a few issues/questions regarding the NAND commands in the latest git main tree. 1) The nand_util.c does not have WATCHDOG_RESET() in the nand_read_skip_bad() and nand_write_skip_bad() while the original nand_write_opts() and nand_read_opts() do. Is there a special reason this is removed? It's likely that watchdog will fail when trying to read/write large files from NAND. 2) "nand write.jffs2" used to allow writing non page-aligned data. So we can have scripts like "tftp 0x2200 u-boot.bin" and "nand write.jffs2 0x2200 0x2 $(filesize)" to automate downloading files to NAND. Now, "nand write(.jffs2)" and nand_write_skip_bad() rejects non page-aligned write. I think we have to either pad the binary file to page-aligned or re-write nand_write_skip_bad(). Is there another way/parameter to write non page-aligned data? 3) In common/cmd_nand.c, nand_load_image() starting at at line 492 call nand_read() at line 514 and line 547. Does it mean that nand_load_image() will read NAND bad blocks? Should they be nand_read_skip_bad() instead? Especially, line 546 has this comment /* FIXME: skip bad blocks */ Thanks, Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] git setlocalversion
Our company uses svn for the source code management but I use git locally to track my development. When I build U-boot, it always complains about "fatal: cannot describe" the SHA1 # of HEAD. It goes back to line 16 of tools/setlocalversion. I know that the error will go away when I tag my git HEAD. But what is the philosophy of this setlocalversion? Should I always tag the top commit of my git tree to maintain a clean U_BOOT_VERSION define? Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Loading Linux Image on AT91SAM9263-EK
You can use U-boot to write the file to NAND as well. The address does not matter as long as your bootcmd is reading the kernel from the same address. Please check your U-boot environment settings and your nand dump of the NAND location (0x20). If you want to get help, post those information. Derek > Date: Wed, 11 Feb 2009 15:33:19 -0400 > From: Amandeep Bhullar > Subject: [U-Boot] Loading Linux Image on AT91SAM9263-EK > To: das...@yahoo.com > > I have questions about loading the Linux Image. Do I just use SAM-BA > v2.7 tool and send file uImage to address 0x20? I tied that and I > got Error: Cant get kernel image. > > Any help will be appreciated !! > > Aman. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] lcd_putc bug fix for tab.
Signed-off-by: Derek Ou
---
common/lcd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 5f73247..2bcdba2 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -187,7 +187,7 @@ void lcd_putc (const char c)
return;
case '\t': /* Tab (8 chars alignment) */
- console_col |= 8;
+ console_col += 8;
console_col &= ~7;
if (console_col >= CONSOLE_COLS) {
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] lcd_putc bug?
In the lcd_putc() of common/lcd.c, line 189 handles tab '\t'. And the following lines: console_col |= 8; console_col &= ~7; seems to have problems. If console_col is 9, it will become 8 after the above two lines, which means instead of tab of 8 spaces, it goes back 1. Is this intentional or a bug? I think it should be console_col += 8; instead of console_col |= 8; Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Environment variables not available during, console initialisation?
Is this a catch 22? If console is initialized after loading environment variables, this means NAND (or other memories) driver are loaded before console being available and there is no console output to debug NAND driver initialization. If console is initialized before loading NAND driver, environment variable is available after the console is configured? Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] NAND jffs2 bug fix - sector size not initialized
NAND jffs2 bug fix - sector size not initialized.
Signed-off-by: Derek Ou
---
common/cmd_jffs2.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c
index 7866c80..f6966f3 100644
--- a/common/cmd_jffs2.c
+++ b/common/cmd_jffs2.c
@@ -1853,6 +1853,8 @@ int mtdparts_init(void)
if (part->size == SIZE_REMAINING)
part->size = id->size - part->offset;
+ part->sector_size = nand_info[id->num].erasesize;
+
DEBUGF("part : name = %s, size = 0x%08lx, offset = 0x%08lx\n",
part->name, part->size, part->offset);
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand sector size is zero in jffs2 cmds
Hi, Wolfgang,
The following patch was tested some time ago. I am in the middle of
another task and can not
verify this patch with the latest code. Should I just reformat my patch
and submit it or should I
wait till I can test it with the latest code?
Also, I found that jffs2 scanning routine does not skip the bad blocks
in NAND in my
previous test. Does anybody else see this behavior?
BTW, what is the best way to submit patches? I tried git-format-patch
approach described in
http://www.denx.de/wiki/U-Boot/GnatsEmail
But git-send-email is not easy to use. I tried just copy and paste but
thunderbird convert all the
tabs into spaces. I ended up using copy and paste and webmail interface
to send out another
patch. But I will love to hear a better way of doing it.
Thanks,
Derek
Wolfgang Denk wrote:
> Dear Derek Ou,
>
> In message <49515bd6.9030...@siconix.com> you wrote:
>
>> The "### ERROR ### Please RESET the board ###" error and the zero NAND
>> sector size problem can be fixed by the following patch. However, the
>> jffs2 scanning routine does not skip the bad blocks in NAND though.
>>
>> Derek
>> * patch **
>> index 7866c80..f6966f3 100644
>> --- a/common/cmd_jffs2.c
>> +++ b/common/cmd_jffs2.c
>> @@ -1853,6 +1853,8 @@ int mtdparts_init(void)
>> if (part->size == SIZE_REMAINING)
>> part->size = id->size - part->offset;
>>
>> + part->sector_size = nand_info[id->num].erasesize;
>> +
>> DEBUGF("part : name = %s, size = 0x%08lx, offset =
>> 0x%08lx\n",
>> part->name, part->size, part->offset);
>>
> Can you please submit a proper patch (after fixing your mailer
> configuration which wraps long lines, thus corrupting the patch)?
>
> See http://www.denx.de/wiki/U-Boot/Patches for instructions.
>
> Best regards,
> Wolfgang Den
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] nand erase cleanmarker and jffs2
Dear all, What is the use of "nand erase clean"? According to the source code, it erases the NAND block and also writes the jffs2 cleanmarker to OOB session. Is this necessary to write a jffs2 file system? I didn't run into any Linux file system problem when I erased a NAND partitaion without clean flag and wrote the jffs2 file system there. Currently, I only have a "jffs2_scan_inode_node() CRC failed on ..." message and I think it's not related to how I erased the partition. Am I right? By the way, the Linux tool seems to indicate that the size of cleanmarker should be 12 bytes. But it seems to be only 8 bytes from our board/u-boot. Which one is correct? Many thanks. Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bad environment block handling
Hi, I think bad blocks are less likely to happen near the first block, which is guaranteed to be good. It may be possible to find NAND chip that guarantee more blocks but I have not encountered one myself. U-boot has the code to skip bad block when reading environment. As Sylvain said, you just need to reserve enough spare blocks. Like his sample, if you have 2 spare blocks after the environment block and using your 1% probability, the chance of all 3 blocks are bad are 1 out of 1,000,000. In this case, the environment will collide with the next partition, which could be your redundant environment or even Linux kernel. Derek > -- > Hi, > > I'm wondering what the best way is to handle bad environment blocks in NAND. > > According to the spec of our supplier a delivered component is considered to > be OK if less than 2% of the blocks are not bad. > This means that for our products we need to take into account that worst case > 2% of the blocks are bad. But even with 1% bad blocks we have an issue: > If the bad blocks are distributed randomly we have a chance of 1/100 * 1/100 > so 1 out of 10.000 that both U-Boot environment blocks are bad. > And actually things could even be worse if the bad blocks are caused by some > manufacturing defect at our supplier and both environment blocks happen to be > bad in a whole batch of ICs. > > Is there a solution for this? > (obviously I am not considering the situation for a single system, where I > just would relocate the environment block; this concerns a production > situation). > > E.g. it would be nice if U-Boot could read the env from the next non-bad > block at/after the env address. > > Has someone experience in this area? Ideas? Suggestions? > > Thanks alot! > Frans Meulenbroeks > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] env_nand malloc not released
Hi, all, In the common/env_nand.c, function env_relocate_spec (for CONFIG_ENV_OFFSET_REDUND) malloc two memory areas in line 296 and 297. If it hits line 308 when both environment areas not found, it will return without freeing the two memory areas. Is this a bug or I am missing something? Thanks, Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand sector size is zero in jffs2 cmds
The "### ERROR ### Please RESET the board ###" error and the zero NAND
sector size problem can be fixed by the following patch. However, the
jffs2 scanning routine does not skip the bad blocks in NAND though.
Derek
* patch **
index 7866c80..f6966f3 100644
--- a/common/cmd_jffs2.c
+++ b/common/cmd_jffs2.c
@@ -1853,6 +1853,8 @@ int mtdparts_init(void)
if (part->size == SIZE_REMAINING)
part->size = id->size - part->offset;
+ part->sector_size = nand_info[id->num].erasesize;
+
DEBUGF("part : name = %s, size = 0x%08lx, offset =
0x%08lx\n",
part->name, part->size, part->offset);
Derek Ou wrote:
> Hi, all,
>
> When I tested jffs2 command for NAND, I found that jffs2_1pass.c::
> jffs2_1pass_build_lists() fails at
>u32 nr_sectors = part->size/part->sector_size;
> because part->sector_size is zero. And cause the "### ERROR ###
> Please RESET the board ###" error when entering the for loop (i <
> nr_sectors), I think.
>
> It looks like the sector_size was not updated in mtdparts_init().
> According to cmd_jffs2.c, the mtdparts_init in the #ifdef
> CONFIG_JFFS2_CMDLINE section calls the parse_mtdparts() and eventually
> reach the following lines in part_validate_nand():
>nand = &nand_info[id->num];
>part->sector_size = nand->erasesize;
> However, the other mtdparts_init(), which is not in the #ifdef
> CONFIG_JFFS2_CMDLINE section, does not call parse_mtdparts() and it
> may lead to the part->sector_size not initialized.
>
> I am not totally familiar with this jffs2 and nand code. Can someone
> review this? Thanks.
> Derek
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] nand sector size is zero in jffs2 cmds
Hi, all, When I tested jffs2 command for NAND, I found that jffs2_1pass.c:: jffs2_1pass_build_lists() fails at u32 nr_sectors = part->size/part->sector_size; because part->sector_size is zero. And cause the "### ERROR ### Please RESET the board ###" error when entering the for loop (i < nr_sectors), I think. It looks like the sector_size was not updated in mtdparts_init(). According to cmd_jffs2.c, the mtdparts_init in the #ifdef CONFIG_JFFS2_CMDLINE section calls the parse_mtdparts() and eventually reach the following lines in part_validate_nand(): nand = &nand_info[id->num]; part->sector_size = nand->erasesize; However, the other mtdparts_init(), which is not in the #ifdef CONFIG_JFFS2_CMDLINE section, does not call parse_mtdparts() and it may lead to the part->sector_size not initialized. I am not totally familiar with this jffs2 and nand code. Can someone review this? Thanks. Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] jffs2_1pass and jffs2_nand_1pass
Hi, all, I am having problem loading jffs2 from NAND with the latest code. After some research, I am getting confused regarding the two files jffs2_1pass.c and jffs2_nand_1pass.c. Some post suggested jffs2_nand_1pass.c to replace jffs2_1pass.c for jffs2_NAND. The git history 08ab4e1780fa63c88dd5a5ab52f4ff4ed1ee1878 seems to be moving away from using the file jffs2_nand_1pass.c. Is this commit incomplete or I should not use the file jffs2_nand_1pass.c at all? Also, I am trying to load jffs2 from NAND with latest code on my at91sam9263ek-based board. I run into the "### ERROR ### Please RESET the board ###" error. Is this a memory space issue? Any suggestion on how to debug? Many thanks. Derek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] scan jffs2 NAND slow and bad block
Dear all, I just enabled CMD_JFFS2 and JFFS2_NAND in the uboot 1.3.4 for my at91sam9263 based board. In general, it works in loading the jffs2 file system and loading files from it. However, it takes almost an hour to scan the jffs2 partition, which is 512 MiB. Is it because of the size of the partition? Linux loads and starts within a minute. How come it takes so long for u-boot? Also, it seems that fsload/scanning FS routine does not skip the bad blocks in NAND. So it complains about "read_nand_cached: error reading nand off 0x", with the address within bad blocks reported by "nand bad". Did I forget something in the configuration? Thanks, Derek my related configuration #undef CONFIG_CMD_FLASH #define CONFIG_CMD_NAND1 #define CONFIG_CMD_JFFS2 #define NAND_MAX_CHIPS1 #define CFG_MAX_NAND_DEVICE1 #define CFG_NAND_BASE0x4000 #define CFG_NAND_DBW_81 #undef CONFIG_JFFS2_CMDLINE #define CONFIG_JFFS2_NAND1 #define CONFIG_JFFS2_DEV"nand0" #define CONFIG_JFFS2_PART_SIZE0x2000 #define CONFIG_JFFS2_PART_OFFSET0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
