All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN
Date: Fri, 24 Apr 2009 10:21:18 -0500	[thread overview]
Message-ID: <20090424152118.GA27635@ld0162-tx32.am.freescale.net> (raw)
In-Reply-To: <9c9fda240904232257o3caa5afeja62c6690b80d5b26@mail.gmail.com>

On Fri, Apr 24, 2009 at 02:57:52PM +0900, Kyungmin Park wrote:
> Actually, I don't like the CONFIG_SYS_MONITOR_LEN approaches, now you
> are consider the bad block at 1.
> But we can also consider the bad block 2, if there two consecutive 2
> bad block at block 1, 2, we should define the CONFIG_SYS_MONITOR_LEN
> as 128KiB * 4 and reserved block block 4 always even though we use 2
> blocks.

There are two separate constants -- the length of data excluding bad
blocks, and the size of the region set aside for that data including bad
blocks.  CONFIG_SYS_MONITOR_LEN is the former.

We may need to do something special when writing back the environment to
find its location if there were any bad blocks, though.

> Right, we should consider bad block at IPL, so my recommendation is
> IPL + u-boot should be fit at block 0

We wouldn't be having this discussion if someone didn't have a u-boot
that didn't fit in block 0.

> 128KiB at OneNAND, 256KiB at Flex-OneNAND. In case of apollon. we
> should reduce the size as 128KiB for OneNAND side. If the IPL + u-boot
> size under 128KiB, Flex-OneNAND also can boot it.

For comparison, powerpc u-boots are pretty much never less than 128KiB,
and with the NAND subsystem are typically larger than 256KiB.  We may
need to boot from OneNAND some day.

> For simplicity How about to use block scheme? we always use block 0
> for boot (IPL + u-boot) whatever block size.

NACK.

-Scott

  reply	other threads:[~2009-04-24 15:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <22617689.32781240550892435.JavaMail.weblogic@epml08>
2009-04-24  5:57 ` [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN Kyungmin Park
2009-04-24 15:21   ` Scott Wood [this message]
2009-04-24 21:47     ` Jean-Christophe PLAGNIOL-VILLARD
2009-03-23  9:02 apgmoorthy
2009-03-23 21:25 ` Scott Wood
2009-03-23 22:09   ` Wolfgang Denk
2009-03-23 22:22     ` Scott Wood
2009-03-23 22:46       ` Wolfgang Denk
2009-03-25  4:13         ` Amit Kumar Sharma
2009-03-25 15:49   ` apgmoorthy
2009-03-27  9:15   ` apgmoorthy
2009-03-30 22:33     ` Scott Wood
2009-03-31  4:12       ` Amit Kumar Sharma
2009-04-12  7:55       ` apgmoorthy
2009-04-23 22:39         ` Scott Wood
2009-04-24  5:05           ` Amit Kumar Sharma
2009-03-31 16:08     ` Alessandro Rubini
2009-03-31 16:13       ` Scott Wood
2009-04-01  4:10         ` Amit Kumar Sharma
2009-04-01 21:55           ` Scott Wood
  -- strict thread matches above, loose matches on Subject: below --
2009-03-09 14:15 Rohit Hagargundgi
2009-03-09 19:42 ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090424152118.GA27635@ld0162-tx32.am.freescale.net \
    --to=scottwood@freescale.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.