[U-Boot-Users] PATCH: RPXlite configuration fixes

[U-Boot-Users] PATCH: RPXlite configuration fixes

[Yuli Barcohen]

The attached patch fixes several bugs in and adds some features to long
orphaned RPXlite port.

CHANGELOG

  Fix RPXlite board configuration.

    - Use correct flash sector size
    - Use correct memory test end address
    - Add support for bzip2 compression
    - Various small fixes

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpxlite.patch.gz
Type: application/octet-stream
Size: 1886 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050605/4f2456c5/attachment.obj 

[U-Boot-Users] PATCH: RPXlite configuration fixes

[Sam Song]

--- Yuli Barcohen <yuli@arabellasw.com> wrote:
> The attached patch fixes several bugs in and adds
> some features to long orphaned RPXlite port.
> 
> CHANGELOG
> 
>   Fix RPXlite board configuration.
> 
>     - Use correct flash sector size

It seems that you adjusted CFG_ENV_SECT_SIZE from 
0x4000 to 0x40000. Is it your flash sector size?

>     - Various small fixes

I cannot understand why CFG_RESET_ADDRESS should be 
set as 0x09900000. Did you test the reset function
with this config? Could u shed me a light on it?

Thanks in advance,

Sam


	

	
		
___________________________________________________________
?????????????? 
http://cn.mail.yahoo.com 

[U-Boot-Users] PATCH: RPXlite configuration fixes

[Yuli Barcohen]

>>>>> Sam Song writes:

    Sam> It seems that you adjusted CFG_ENV_SECT_SIZE

No, I used CFG_ENV_SECT_SIZE instead of CFG_ENV_SIZE. It's not the
same. BTW, the original comment mentioned "Total Size of Environment
Sector" which is not CFG_ENV_SIZE.

    Sam> from 0x4000 to 0x40000. Is it your flash sector size?

Yes, it is. There are four Am29LV800BB chips so you can't have 0x4000
bytes in sector (this would require 4KB sector on individual flash chip
while in fact the smallest sectors are 8KB). The board is configured for
high boot (don't know why Embedded Planet designers used high boot with
bottom boot block flashes) so the U-Boot "lives" at 0xFFF00000. I put
the environment to the next sector. The sector's size is 4x64KB =
0x40000. With the original configuration, saveenv must fail and it
indeed failed. Have you got an RPXlite board with different flash
configuration?

    Sam> I cannot understand why CFG_RESET_ADDRESS should be set as
    Sam> 0x09900000.

It can be set to any illegal address so that memory access at this
address will cause checkstop and then reset. 0x09900000 was used on
some other boards, it has no special meaning.

    Sam> Did you test the reset function with this config?

Of course, I did. I never send untested patches.

    Sam> Could u shed me a light on it?

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] PATCH: RPXlite configuration fixes

[Sam Song]

--- Yuli Barcohen <yuli@arabellasw.com> wrote:
> No, I used CFG_ENV_SECT_SIZE instead of
> CFG_ENV_SIZE. It's not the same. BTW, the original 
> comment mentioned "Total Size of Environment
> Sector" which is not CFG_ENV_SIZE.

Ummm, CFG_ENV_SIZE is really a misleading config item.
No matter how small the ENV size is, it take up one
or several FLASH sectors. I have no idea when we use
CFG_ENV_SIZE:-)

> Sam> from 0x4000 to 0x40000. Is it your flash
> > sector size?
> 
> Yes, it is. There are four Am29LV800BB chips so you
> can't have 0x4000 bytes in sector (this would 
> require 4KB sector on individual flash chip
> while in fact the smallest sectors are 8KB). The
> board is configured for high boot (don't know why
> Embedded Planet designers used high boot with
> bottom boot block flashes) so the U-Boot "lives" at
> 0xFFF00000. I put 

So they produce other kind of rpxlite to work right in
low boot mode with bottom boot block flashes later:-)

> the environment to the next sector. The sector's
> size is 4x64KB = 0x40000. With the original
> configuration, saveenv must fail and it
> indeed failed. 

Well, it failed on your rpxlite board but doesn't
mean it would fail on Yoo.Jonghoon's rpxlite board:-)

> Have you got an RPXlite board with different flash
> configuration?

Yeah, I got one. It uses 4 AM29DL323DB90VI devices
(4x8bit) in 16MB(4x4MB) and leaves the u-boot
home at 0xff000000. I ported u-boot on this one
and named RPXlite DW as 2.4 Linux code did.

[U-Boot-Users] PATCH: RPXlite configuration fixes

[Wolfgang Denk]

In message <20050606131237.32918.qmail@web15906.mail.cnb.yahoo.com> you wrote:
> 
> Ummm, CFG_ENV_SIZE is really a misleading config item.

Ummm... and which part of the documentation in  the  README  did  you
fail to understand?

> No matter how small the ENV size is, it take up one
> or several FLASH sectors. I have no idea when we use
> CFG_ENV_SIZE:-)

You did read the README, didn't you?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We all agree on the necessity of compromise. We just can't agree  on
when it's necessary to compromise."
                - Larry Wall in  <1991Nov13.194420.28091@netlabs.com>

[U-Boot-Users] PATCH: RPXlite configuration fixes

[Yuli Barcohen]

>>>>> Sam Song writes:

    Yuli> No, I used CFG_ENV_SECT_SIZE instead of CFG_ENV_SIZE. It's not
    Yuli> the same. BTW, the original comment mentioned "Total Size of
    Yuli> Environment Sector" which is not CFG_ENV_SIZE.

    Sam> Ummm, CFG_ENV_SIZE is really a misleading config item.  No
    Sam> matter how small the ENV size is, it take up one or several
    Sam> FLASH sectors. I have no idea when we use CFG_ENV_SIZE:-)

This is explained in details in the README.

    Sam> from 0x4000 to 0x40000. Is it your flash sector size?

    Yuli> Yes, it is. There are four Am29LV800BB chips so you can't have
    Yuli> 0x4000 bytes in sector (this would require 4KB sector on
    Yuli> individual flash chip while in fact the smallest sectors are
    Yuli> 8KB). The board is configured for high boot (don't know why
    Yuli> Embedded Planet designers used high boot with bottom boot
    Yuli> block flashes) so the U-Boot "lives" at 0xFFF00000. I put

    Sam> So they produce other kind of rpxlite to work right in low boot
    Sam> mode with bottom boot block flashes later:-)

Do you mean the DW series?

    Yuli> the environment to the next sector. The sector's size is
    Yuli> 4x64KB = 0x40000. With the original configuration, saveenv
    Yuli> must fail and it indeed failed.

    Sam> Well, it failed on your rpxlite board but doesn't mean it would
    Sam> fail on Yoo.Jonghoon's rpxlite board:-)

Don't know. If the saveenv works OK, why to have hard-coded environment
in the configuration file? Anyway, if anybody knows for what board old
values are correct, I'd be happy to add appropriate #ifdefs. Maybe there
are configurations using only two flash chips? In any case, new
configuration should cover them all.

    Yuli> Have you got an RPXlite board with different flash
    Yuli> configuration?

    Sam> Yeah, I got one. It uses 4 AM29DL323DB90VI devices (4x8bit) in
    Sam> 16MB(4x4MB) and leaves the u-boot home at 0xff000000. I ported
    Sam> u-boot on this one and named RPXlite DW as 2.4 Linux code did.

But it's a different board family though I'm not sure having two
separate ports is justified. Probably it's possible to handle the
differences in the Makefile.

    Sam> From your discussion, you assume there is one standard rpxlite
    Sam> board.

No, I don't, I work with different Embedded Planet boards and know their
product range, more or less. In any case, if there are four flash chips,
minimal sector size usually is 32KB unless there really is some flash
with 4KB sectors. And if the U-Boot is configured for high boot (the
original port is), why should the environment be placed in the middle of
the flash (offset 0x8000 from the flash base)?

    Sam> Actually, there are at least five different combination boards
    Sam> known as RPXlite CW.

Yes, but AFAIK in the case of high boot it does not matter.

    Sam> So your changelog on FLASH size could use update rather than
    Sam> correct.

    Sam> I cannot understand why CFG_RESET_ADDRESS
    Sam> should be set as 0x09900000.

    Yuli> It can be set to any illegal address so that memory access at
    Yuli> this address will cause checkstop and then reset. 0x09900000
    Yuli> was used on some other boards, it has no special meaning.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] PATCH: RPXlite configuration fixes

[Sam Song]

--- Yuli Barcohen <yuli@arabellasw.com> wrote:
> > I have no idea when we use
> > CFG_ENV_SIZE:-)
> 
> This is explained in details in the README.

Thanks. Wolfgang also suggested. But I use :-)
is for joking with CFG_ENV_SIZE in the old code
of RPXlite. It confused me at that time:-)

> > So they produce other kind of rpxlite to
> > work right in low boot mode with bottom boot 
> > block flashes later:-)
> 
> Do you mean the DW series?

Yeah.

> Maybe there are configurations using only two flash 
> chips?

Ummm, I amn't sure about it. 

> In any case, new configuration should cover 
> them all.

That would be Great! In addition, this code also
need to upgrade to new state.

> But it's a different board family though I'm not
> sure having two separate ports is justified. 
> Probably it's possible to handle the
> differences in the Makefile.

EP uses plantcore to implement one image for all
rpxlite board. Its flexible characteristic impressed
me a lot. It's possible to combine these two ports.

> product range, more or less. In any case, if there
> are four flash chips, minimal sector size usually 
> is 32KB unless there really is some flash
> with 4KB sectors. And if the U-Boot is configured
> for high boot (the original port is), why should 
> the environment be placed in the middle of
> the flash (offset 0x8000 from the flash base)?

Good point. I come to know that you have the same
board as Yoo.'s. Both have 4 AM29LV800BB chips. If so,
this is really a long orphaned fix.

Thanks for this clarification,

Sam

__________________________________________________
???????????????
http://cn.mail.yahoo.com

[U-Boot-Users] Compile-time flash dependencies (was: PATCH: RPXlite configuration fixes)

[Yuli Barcohen]

>>>>> Sam Song writes:

...

    Yuli> In any case, new configuration should cover them all.

    Sam> That would be Great! In addition, this code also need to
    Sam> upgrade to new state.

I don't mean it already covers DW boards (I haven't got one) though no
significant modifications should be necessary. IIRC, DW boards use
CFI-compliant flash so common CFI driver can be used instead of the
board-specific one.

    Yuli> But it's a different board family though I'm not sure having
    Yuli> two separate ports is justified. Probably it's possible to
    Yuli> handle the differences in the Makefile.

    Sam> EP uses plantcore to implement one image for all rpxlite
    Sam> board. Its flexible characteristic impressed me a lot. It's
    Sam> possible to combine these two ports.

PlanetCore saves its environment in the I2C EEPROM so it's not affected
by the flash configuration. Also, the EEPROM contains exact board
hardware configuration (board version, RAM size, flash size, etc.)
probably burned there during manufacturing process so PlanetCore can
initialise the board accordingly. It's possible to use this information
in the U-Boot but some hard-coded values still remain. CFG_MONITOR_LEN
and CFG_ENV_SECT_SIZE are a problem, especially now when we've got
universal CFI driver. In theory, CFI driver detects the flash
configuration automatically so the same U-Boot image can work on
different boards. In real world, CFG_MONITOR_LEN and CFG_ENV_SECT_SIZE
must be specified in compile time so different flashes can result in
different images. I'd like to remove these compile time values. Any
ideas if and how it's possible?

...

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] Compile-time flash dependencies (was: PATCH: RPXlite configuration fixes)

[Wolfgang Denk]

Dear Yuli,

in message <17060.29833.578253.397330@astp0002.localdomain> you wrote:
> 
> different boards. In real world, CFG_MONITOR_LEN and CFG_ENV_SECT_SIZE
> must be specified in compile time so different flashes can result in

You can define a CFG_MONITOR_LEN that matches all  supported  boards;
CFG_ENV_SECT_SIZE is more difficult to handle.

> different images. I'd like to remove these compile time values. Any
> ideas if and how it's possible?

The problem is that in the current code a lot of dependency  checking
is  doen at compile time. This is *intentional* to keep the code size
minimal. If you can  figure  out  how  to  avoid  #defined  CFG_ENV_*
settings  while  *not*  increasing the code size your patches will be
welcome.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
        "That we but teach bloody instructions,
        which, being taught, return to plague the inventor..."

[U-Boot-Users] Compile-time flash dependencies (was: PATCH: RPXlite configuration fixes)

[Yuli Barcohen]

>>>>> Wolfgang Denk writes:

    Yuli> different boards. In real world, CFG_MONITOR_LEN and
    Yuli> CFG_ENV_SECT_SIZE must be specified in compile time so
    Yuli> different flashes can result in

    Wolfgang> You can define a CFG_MONITOR_LEN that matches all
    Wolfgang> supported boards;

It's what I do in my ports.

    Wolfgang> CFG_ENV_SECT_SIZE is more difficult to handle.

    Yuli> different images. I'd like to remove these compile time
    Yuli> values. Any ideas if and how it's possible?

    Wolfgang> The problem is that in the current code a lot of
    Wolfgang> dependency checking is doen at compile time. This is
    Wolfgang> *intentional* to keep the code size minimal. If you can
    Wolfgang> figure out how to avoid #defined CFG_ENV_* settings while
    Wolfgang> *not* increasing the code size

It's what I'm trying to do. I'd like to clarify "increasing the code
size" concern which appears from time to time on the list. As we all
know, U-Boot occupies entire flash sector (or several sectors). So,
IMHO, if the increase does not require additional sector, the increase
should not be a problem. Even if you're concerned about RAM size, I'm
not sure U-Boot size can be an issue. In most cases, there is at least
8MB of RAM, so if U-Boot is 170K or 200K should not make any
difference. I personally never had such an issue with our customers. In
cases when such a difference is critical, current method (compile-time
CFG_ENV_SECT_SIZE) can be used. In any case, I believe that run-time vs
compile-time code size difference can be 2-3K in the worst case.

    Wolfgang> your patches will be welcome.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] Compile-time flash dependencies (was: PATCH: RPXlite configuration fixes)

[Wolfgang Denk]

In message <17060.34001.772438.243816@astp0002.localdomain> you wrote:
>
> It's what I'm trying to do. I'd like to clarify "increasing the code
> size" concern which appears from time to time on the list. As we all
> know, U-Boot occupies entire flash sector (or several sectors). So,
> IMHO, if the increase does not require additional sector, the increase

You assume that there is flash on a board. There are boards which use
a 128 kB ROM, and still are able to use a decent set of features.  Of
course  this requires optimization, and omitting some stuff. It's not
a matter of using an additional sector or  not,  it's  as  simple  as
works or does not work.

> should not be a problem. Even if you're concerned about RAM size, I'm
> not sure U-Boot size can be an issue. In most cases, there is at least
> 8MB of RAM, so if U-Boot is 170K or 200K should not make any
> difference. I personally never had such an issue with our customers. In

I do, and I will strictly look at the code size. The rules  are  well
known.

> cases when such a difference is critical, current method (compile-time
> CFG_ENV_SECT_SIZE) can be used. In any case, I believe that run-time vs
> compile-time code size difference can be 2-3K in the worst case.

Maybe. Then it's 2-3k which can be saved, and shall be saved.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
HP had a unique policy of allowing its engineers to take  parts  from
stock  as long as they built something. "They figured that with every
design, they were getting a better engineer. It's a policy I urge all
companies  to  adopt."  -  Apple  co-founder  Steve  Wozniak,   "Will
Wozniak's class give Apple to teacher?" EE Times, June 6, 1988, pg 45

[U-Boot-Users] Compile-time flash dependencies (was: PATCH: RPXlite configuration fixes)

[Yuli Barcohen]

>>>>> Wolfgang Denk writes:

    Yuli> It's what I'm trying to do. I'd like to clarify "increasing
    Yuli> the code size" concern which appears from time to time on the
    Yuli> list. As we all know, U-Boot occupies entire flash sector (or
    Yuli> several sectors). So, IMHO, if the increase does not require
    Yuli> additional sector, the increase

    Wolfgang> You assume that there is flash on a board. There are
    Wolfgang> boards which use a 128 kB ROM, and still are able to use a
    Wolfgang> decent set of features.  Of course this requires
    Wolfgang> optimization, and omitting some stuff. It's not a matter
    Wolfgang> of using an additional sector or not, it's as simple as
    Wolfgang> works or does not work.

But we're discussing only "environment in flash" case. All the rest is
unchanged. The CFG_ENV_SECT_SIZE is relevant for flash only, isn't it?
Also, if CFG_ENV_SECT_SIZE is defined, the existing mechanism will
work. I'd suggest any changes only for the case when CFG_ENV_SECT_SIZE
is undefined so the programmer always can chose between compile-time and
run-time approaches.

    Yuli> should not be a problem. Even if you're concerned about RAM
    Yuli> size, I'm not sure U-Boot size can be an issue. In most cases,
    Yuli> there is at least 8MB of RAM, so if U-Boot is 170K or 200K
    Yuli> should not make any difference. I personally never had such an
    Yuli> issue with our customers. In

    Wolfgang> I do, and I will strictly look at the code size. The rules
    Wolfgang> are well known.

    Yuli> cases when such a difference is critical, current method
    Yuli> (compile-time CFG_ENV_SECT_SIZE) can be used. In any case, I
    Yuli> believe that run-time vs compile-time code size difference can
    Yuli> be 2-3K in the worst case.

    Wolfgang> Maybe. Then it's 2-3k which can be saved, and shall be
    Wolfgang> saved.

So look at the saveenv code (in common/env_flash.c). The following
definition:

#if defined(CFG_ENV_SECT_SIZE) && (CFG_ENV_SECT_SIZE > CFG_ENV_SIZE)
	ulong	flash_offset;
	uchar	env_buffer[CFG_ENV_SECT_SIZE];
#else

allocates CFG_ENV_SECT_SIZE bytes on stack, in many cases this is
256KB. So we don't care for RAM data size but fight for every byte of
code size? Anyway, nobody is forced to use new mechanism if and when I
develop it. Also, I see no reason why U-Boot should be less convenient
or less flexible than, say, PlanetCore.

Unrelated question, also regarding the environment. It looks like
CFG_ENV_IS_EMBEDDED is unnecessary because ENV_IS_EMBEDDED is calculated
and used. What do you think?

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] Compile-time flash dependencies

[Wolfgang Denk]

Dear Yuli,

in message <17061.20898.318765.498613@astp0002.localdomain> you wrote:
> 
> But we're discussing only "environment in flash" case. All the rest is

Yes. I see no reason for a "but" in this sentence, though.

> unchanged. The CFG_ENV_SECT_SIZE is relevant for flash only, isn't it?

Yes. And the memory footprint  for  U-Boot  on  the  boot  device  is
essential.

> So look at the saveenv code (in common/env_flash.c). The following
> definition:
...
> allocates CFG_ENV_SECT_SIZE bytes on stack, in many cases this is
> 256KB. So we don't care for RAM data size but fight for every byte of
> code size? Anyway, nobody is forced to use new mechanism if and when I

Right. Normally U-Boot is used to boot an OS which  requires  several
megabytes  of  RAM  so  we  don't have to worry about allocating even
bigger temporary buffers in U-Boot.

> develop it. Also, I see no reason why U-Boot should be less convenient
> or less flexible than, say, PlanetCore.

I agree, if it can be avoided. But we have  clear  priorities.  Small
memory  footprint  is  much  hicher on the list than comparing U-Boot
against PlanetCore.

> Unrelated question, also regarding the environment. It looks like
> CFG_ENV_IS_EMBEDDED is unnecessary because ENV_IS_EMBEDDED is calculated
> and used. What do you think?

It was needed once, and I guess  nobody  ever  spent  the  effort  to
actually test all related platforms if it can be savely removed.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>  Is there a way to determine Yesterday's date using Unix utilities?
         echo "what is yesterday's date?" | /bin/mail root
         -- Randal L. Schwartz in <ukbuh2y982.fsf@julie.teleport.com>

[U-Boot-Users] PATCH: RPXlite configuration fixes)

[Sam Song]

Yuli Barcohen <yuli@arabellasw.com> wrote:
> I don't mean it already covers DW boards (I haven't
> got one) though no significant modifications should 
> be necessary.

I didn't deem it, either.

> DW boards use CFI-compliant flash so common CFI 
> driver can be used instead of the board-specific 
> one.

Well, although DW use CFI-compliant flash, it still
work with a board-specific one at least in CVS. I 
once used CFI driver on DW but failed.

> PlanetCore saves its environment in the I2C EEPROM
> so PlanetCore can initialise the board accordingly. 
> It's possible to use this information

If so, U-Boot and PlanetCore can share one ENV to
work??? IMHO, ENV in EEPROM of PlanetCore use 
it's own definition keyword. Only to change
ENV of U-Boot can meet the requirement of 
PlanetCore. It will decrease u-boot ENV variability.

> in the U-Boot but some hard-coded values still
> remain. CFG_MONITOR_LEN and CFG_ENV_SECT_SIZE 

If used EEPROM for ENV home, could we need to set 
CFG_ENV_SECT_SIZE?

Actually, I am worring about one thing if we wanted
to combine CW nad DW port. That's how to deal with
HIGH boot mode[DW] and LOW boot mode[CW] in one image.

> time values. Any
> ideas if and how it's possible?

The "possible" I used was really a draft idea. Don't
take it seriously. To me, it isn't worthwhile to 
implement it. CW is too old to be popular nowdays.
Take a look at it's main page if avaiable. 

http://www.embeddedplanet.com/products/lite.asp

In one word, you fix on RPXlite is a treasure. Just
stop and keep that. Those who are interested on 
RPXlite[C/DW] can get enough hints from exist
port work in CVS.

Thanks for your time,

Sam


		
___________________________________________________________
????G??????????????????
http://cn.mail.yahoo.com/?id=77072

[U-Boot-Users] PATCH: RPXlite configuration fixes)

[Yuli Barcohen]

>>>>> Sam Song writes:

...

    Yuli> PlanetCore saves its environment in the I2C EEPROM so
    Yuli> PlanetCore can initialise the board accordingly. It's possible
    Yuli> to use this information

    Sam> If so, U-Boot and PlanetCore can share one ENV to work??? IMHO,
    Sam> ENV in EEPROM of PlanetCore use it's own definition
    Sam> keyword. Only to change ENV of U-Boot can meet the requirement
    Sam> of PlanetCore. It will decrease u-boot ENV variability.

U-Boot and PlanetCore can't share the same environment but
board-specific code in U-Boot can use PlanetCore environment to
initialise U-Boot's one.

    Yuli> in the U-Boot but some hard-coded values still
    Yuli> remain. CFG_MONITOR_LEN and CFG_ENV_SECT_SIZE

    Sam> If used EEPROM for ENV home, could we need to set
    Sam> CFG_ENV_SECT_SIZE?

No, if the environment is not in flash this problem does not exist but
the EEPROM is too small for U-Boot's environment (and Wolfgang always
advises against using EEPROM for environment:).

    Sam> Actually, I am worring about one thing if we wanted to combine
    Sam> CW nad DW port. That's how to deal with HIGH boot mode[DW] and
    Sam> LOW boot mode[CW] in one image.

There will be no single binary image for all boards but can be single
source which also reduces maintenance efforts.

...

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] PATCH: RPXlite configuration fixes)

[Sam Song]

--- Yuli Barcohen <yuli@arabellasw.com> wrote:
> There will be no single binary image for all boards
> but can be single
> source which also reduces maintenance efforts.

Ummm, I do agree with it:-)

NOW TIME : 21:33  -- Good night:-)

Sam


		
___________________________________________________________ 
????G???????????????????
http://cn.mail.yahoo.com/?id=77071

[U-Boot-Users] PATCH: RPXlite configuration fixes

[Wolfgang Denk]

In message <17059.20977.593589.618317@astp0002.localdomain> you wrote:
> 
> CHANGELOG
> 
>   Fix RPXlite board configuration.
> 
>     - Use correct flash sector size
>     - Use correct memory test end address
>     - Add support for bzip2 compression
>     - Various small fixes

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Immortality consists largely of boredom.
	-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8