On Mon, Dec 21, 2009 at 04:30:40PM +0530, apgmoorthy wrote:
> Hunk 1:
> env_addr += CONFIG_ENV_ADDR & (onenand_mtd.eraseregions[0].erasesize-1);
>
> Hunk 2:
> env_addr += CONFIG_ENV_ADDR & (onenand_mtd.eraseregions[0].erasesize-1);
I'd say it should be the board config file's responsibility to pr
Hi Scott,
> >>>
> >>> Hunk 2:
> >>> + if (FLEXONENAND(this)) {
> >>> + env_addr <<= 1;
> >>> + instr.len <<=
> >> onenand_mtd.eraseregions[0].numblocks == 1 ?
> >>> + 2 : 1;
> >>> + }
> >>>
> >>> This should not break any other
Hi Sanjeev,
>
> Is there any update on the fix/proposal?
>
> I am trying to build for omap3_evm; but see the same problem.
> My repo is currently at:
> bb3bcfa : Merge branch 'next' of ../next
> a200a7c : Update CHANGELOG; prepare Prepare v2009.11
>
As Scott pointed out rightly, my previou
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Tom
> Sent: Tuesday, December 01, 2009 8:10 PM
> To: apgmoorthy
> Cc: 'Scott Wood'; u-boot@lists.denx.de; kyungmin.p...@samsung.com
> Subject: Re
apgmoorthy wrote:
> Hi Scott,
>
>>> Hunk 1:
>>>env_addr = CONFIG_ENV_ADDR;
>>>+ if (FLEXONENAND(this))
>>>+ env_addr <<= 1;
>>>
>>> Hunk 2:
>>> + if (FLEXONENAND(this)) {
>>> + env_addr <<= 1;
>>> + instr.len <<=
>> onenan
Hi Scott,
> >
> > Hunk 1:
> >env_addr = CONFIG_ENV_ADDR;
> >+ if (FLEXONENAND(this))
> >+ env_addr <<= 1;
> >
> > Hunk 2:
> > + if (FLEXONENAND(this)) {
> > + env_addr <<= 1;
> > + instr.len <<=
> onenand_mtd.eraseregion
apgmoorthy wrote:
> Hi Scott,
>
>> Are they going to be the same on all boards? We let the
>> board determine the environment location for other types of storage.
>>
> OK
>
>> How about just using CONFIG_ENV_ADDR/CONFIG_ENV_SIZE? On
>> boards that must dynamically support multiple possibili
Hi Scott,
> Are they going to be the same on all boards? We let the
> board determine the environment location for other types of storage.
>
OK
> How about just using CONFIG_ENV_ADDR/CONFIG_ENV_SIZE? On
> boards that must dynamically support multiple possibilities,
> define it as an expre
apgmoorthy wrote:
> I felt moving these macros "include/linux/mtd/onenand.h" will be ideal in this
> scenario.
Are they going to be the same on all boards? We let the board determine
the environment location for other types of storage.
How about just using CONFIG_ENV_ADDR/CONFIG_ENV_SIZE? On b
gmin.p...@samsung.com
> Subject: Re: [U-Boot] Breakage on arm/next
>
> > Could the macros defined in apollo.h also be defined in the other
> > target board's config file ?
>
> I don't think so (my board is one of the affected ones).
>
> The macros are CO
> Could the macros defined in apollo.h also be defined in the
> other target board's config file ?
I don't think so (my board is one of the affected ones).
The macros are CONFIG_ENV_ADDR_FLEX and CONFIG_ENV_SIZE_FLEX . I just
don't have the flex device.
In the commit that introduced the problem,
apgmoorthy wrote:
> Hi Tom,
>
>
> Moving these Macro definitions to "include/linux/mtd/onenand.h" looks more
> viable.
> I can send across the patch. Please comment.
>
Could the macros defined in apollo.h also be defined in the
other target board's config file ?
Thank you for looking into
Hi Tom,
Amul is out-of-office for sometime.
Excuse us for the delay.
>>In rebasing arm/next against u-boot/next.
>>There is a general error with targets that use onenand.
>>This includes the targets
>>nk8815_onenand
>>omap3_evm
>>smdkc100
>>I believe the error is from
>>commit c758e947aa7d39a2
In rebasing arm/next against u-boot/next.
There is a general error with targets that use onenand.
This includes the targets
nk8815_onenand
omap3_evm
smdkc100
The error message is
env_onenand.c: In function 'env_relocate_spec':
env_onenand.c:70: error: 'CONFIG_ENV_ADDR_FLEX' undeclared (first use
14 matches
Mail list logo
