Re: [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN
Hi,
On Fri, Apr 24, 2009 at 2:28 PM, AYYANARPONNUSAMY GANGHEYAMOORTHY moorthy.apg@samsung.com wrote:
Hi Scott, On Apr 24, 2009 07:39 (GMT+09:00) Scott Woodscottwood@freescale.com wrote
apgmoorthy wrote: This is done by the Post : [U-Boot] [PATCH 2/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN
What do you feel about getting this one inside u-boot-nand-flash ?
Such a change should go through the board maintainer, who knows better what the actual length is.
- Correct , I got your point.
Hi Kyungmin, Can you please make a call on this , for apollon and get CONFIG_SYS_MONITOR_LEN in.
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.
Right, we should consider bad block at IPL, so my recommendation is IPL + u-boot should be fit at 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 simplicity How about to use block scheme? we always use block 0 for boot (IPL + u-boot) whatever block size.
Thank you, Kyungmin Park
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
On 10:21 Fri 24 Apr , Scott Wood wrote:
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 detect the u-boot.bin size dynamicly instead of staticly
as Scott NACK
Best Regards, J.
participants (3)
-
Jean-Christophe PLAGNIOL-VILLARD -
Kyungmin Park -
Scott Wood