headers
Wolter Kamphuis | 1 Dec 2003 18:10
Picon
Picon

Re: reading environment from flash fails

Wolfgang Denk wrote:
> In message <3FC7802B.7010506 <at> wkamphuis.student.utwente.nl> you wrote:
> 
>>We define:
>>#define CFG_MONITOR_BASE 0xFFF00000
>>#define CFG_ENV_SECT_SIZE (128*1024)
>>#define CFG_ENV_SIZE (2*1024)
>>#define CFG_ENV_ADDR (CFG_MONITOR_BASE + CFG_ENV_SECT_SIZE - CFG_ENV_SIZE)
> 
> 
> The CFG_ENV_ADDR definition makes no sense to me. If  it  results  in
> the intended value than by pure chance, not by any deeper logic.
> 
> 
U-boot is located at 0xfff00000 up to 0xfff20000. I would like to save 
my environment in the same sector as u-boot, but in the last two Kb's, 
thus at 0xfff1f800-0xfff20000

(0xfff00000 + 0x20000 - 0x800 = 0xfff1f800 = starting address for env)

>>Shouldn't gd->env_addr be equal to CFG_ENV_ADDR? Now my saved 
>>environment settings aren't read and after a reset all settings are 
>>restored to the defaults.
>
> 
> I don't know which board you're talking about, and I don't understand
> how your patch and your question are related to each other. From this
> message it sounds as if you want to put the environment in flash, but
> your code #defines CFG_ENV_IS_IN_NVRAM (at least in some cases).
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stephan Linz | 1 Dec 2003 18:23
Picon

[ANNOUNCEMENT] NIOS: more doc, rebuild board configuration

Hi NIOS developers,

yesterday I've finished my NIOS Development Kit comparison. As an result of 
it I've expand the NIOS documentation end rebuild the board configuration. 
The work is accessible by patches:

(1) NIOS documentation
----------------------
http://prdownloads.sourceforge.net/cdk4nios/u-boot-20031125cvs-nios_doc.patch.bz2

In this patch you will find some more documentations:
    doc/README.nios              supplementations
    doc/README.nios_DK           Development Kit (DK) hardware overview
    doc/README.dk1c20_std32      NIOS CPU standard_32 at DK-1C20
    doc/README.dk1s10_std32      NIOS CPU standard_32 at DK-1S10
    doc/README.dk1s40_std32      NIOS CPU standard_32 at DK-1S10
    doc/README.dk20k200_std32    NIOS CPU standard_32 at DK-20K200
    doc/README.nios_CFG_NIOS_CPU config. reference for CFG_NIOS_CPU_


(2) LAN91C111
-------------
http://prdownloads.sourceforge.net/cdk4nios/u-boot-20031125cvs-smc91111_fix.patch.bz2

Pending patch. We need it at NIOS platforms to avoid MAC setup failures. I'm 
not happy about the state of this patch ...

(3) new DK1C20 configuration
----------------------------
http://prdownloads.sourceforge.net/cdk4nios/u-boot-20031125cvs-dk1c20_reconfig.patch.bz2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Dec 2003 19:02
Picon
Picon
Favicon

Re: reading environment from flash fails

Dear Wolter,

in message <3FCB7600.6040402 <at> wkamphuis.student.utwente.nl> you wrote:
>
> U-boot is located at 0xfff00000 up to 0xfff20000. I would like to save 
> my environment in the same sector as u-boot, but in the last two Kb's, 
> thus at 0xfff1f800-0xfff20000

Don't do this. This is by far too dangerous. Each "saveenv" will open
a window in time where your system will  not  recover  from  a  power
loss. DO NOT DO THIS.

> (0xfff00000 + 0x20000 - 0x800 = 0xfff1f800 = starting address for env)

This makes no sense. Never place the environment in any flash  sector
that contains any other data you need.

> Ok, now the problem is I don't know how to tell the linker where to 
> store the environment. If I add
> 
> . = env_offset;
> common/environment.o    (.text)
> 
> to the u-boot.lds I get "cannot move location counter backwards (from 
> fff07b10 to 0061f800)". Where does the 0061f800 comes from?

That's what was computed as env_offset given your definitions.

> Letting u-boot store its environment outside the u-boot sector 
> (<0xfff0000) works perfectly but will cost me a flash sector dedicated
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Dec 2003 19:02
Picon
Picon
Favicon

Re: reading environment from flash fails

Dear Wolter,

in message <3FCB7600.6040402 <at> wkamphuis.student.utwente.nl> you wrote:
>
> U-boot is located at 0xfff00000 up to 0xfff20000. I would like to save 
> my environment in the same sector as u-boot, but in the last two Kb's, 
> thus at 0xfff1f800-0xfff20000

Don't do this. This is by far too dangerous. Each "saveenv" will open
a window in time where your system will  not  recover  from  a  power
loss. DO NOT DO THIS.

> (0xfff00000 + 0x20000 - 0x800 = 0xfff1f800 = starting address for env)

This makes no sense. Never place the environment in any flash  sector
that contains any other data you need.

> Ok, now the problem is I don't know how to tell the linker where to 
> store the environment. If I add
> 
> . = env_offset;
> common/environment.o    (.text)
> 
> to the u-boot.lds I get "cannot move location counter backwards (from 
> fff07b10 to 0061f800)". Where does the 0061f800 comes from?

That's what was computed as env_offset given your definitions.

> Letting u-boot store its environment outside the u-boot sector 
> (<0xfff0000) works perfectly but will cost me a flash sector dedicated
(Continue reading)

Permalink | Reply | 0 comments |
headers
Woodruff, Richard | 1 Dec 2003 19:07
Picon
Favicon

[PATCH] probe for smc91111.c before chip init.

Hello,

This patch adds: 
 - a probe to verify the existence of the 91c111 chip prior to attempting to
init registers.  This allows the code to live in systems where the chip is
not present or disabled.  Prior to this a "tftp" or "dhcp" would hang if
attempted when the chip was not there, now it just returns immediately.  The
system I use has a plug in ether debug board, so this probe is useful and
allows having a single image around.

 - a mac address set function outside of smc_open.  This proves useful when
boot happens with out the chip being touched but the kernel wants etherent.
The current Linux kernel drivers assume the MAC address is good so having it
set here saves messing around with the kernel driver.

 - all signed characters are now unsigned.  A previous patch was issued with
out changing all references.  This gets them all.

Regards,

Richard W.
Attachment (smc_probe.diff): application/octet-stream, 4341 bytes
Attachment (smc_probe.changelog): application/octet-stream, 192 bytes
Permalink | Reply | 1 comment |
headers
Woodruff, Richard | 1 Dec 2003 19:21
Picon
Favicon

[PATCH] cache flush for arm925.

Hello,

The included patch adds a cache flush for the arm925 cpu.  This is necessary
when downloading and executing code (as icache is currently enabled).  The
flush is both an I and D flush, though I is all that is strictly necessary
at the moment.

Regards,

Richard W.
Attachment (925_flush.diff): application/octet-stream, 1914 bytes
Attachment (925_flush.changelog): application/octet-stream, 123 bytes
Permalink | Reply | 1 comment |
headers
Kiran Mandava | 1 Dec 2003 19:29

compiler for 8260

Hello all,

	I am trying to compile code for Ep8260 board. which compiler should
i use for 8260 processor as its core is 6xx compatible core right. should i
use a 8xx compiler or 6xx compiler.

thanks,
kiran
	

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
Permalink | Reply | 3 comments |
headers
Woodruff, Richard | 1 Dec 2003 20:11
Picon
Favicon

[PATCH] cmd_flash.c

Hello,

This patch causes cmd_flash.c to report errors.  There are several cases
where the flash commands can return silently even if they fail.  This is can
lead to further problems.

...done with some of the easy patches.  One of the people here just got a
USB client serial console running, it can do Kermit at blazing speed and
allows the use of u-boot with out a rs232 header on OMAPs. Don't have the
time to break up all the needed patches.

Regards,

Richard W.
Attachment (cmd_flash.diff): application/octet-stream, 2494 bytes
Attachment (cmd_flash.changelog): application/octet-stream, 110 bytes
Permalink | Reply | 1 comment |
headers
Woodruff, Richard | 1 Dec 2003 20:24
Picon
Favicon

RE: [PATCH] probe for smc91111.c before chip init.

Seems I did the order wrong in the diff.  Here is the corrected version.

Sorry/Regards,

Richard W.

-----Original Message-----
From: Woodruff, Richard 
Sent: Monday, December 01, 2003 12:07 PM
To: u-boot-users <at> lists.sourceforge.net
Subject: [PATCH] probe for smc91111.c before chip init.

Hello,

This patch adds: 
 - a probe to verify the existence of the 91c111 chip prior to attempting to
init registers.  This allows the code to live in systems where the chip is
not present or disabled.  Prior to this a "tftp" or "dhcp" would hang if
attempted when the chip was not there, now it just returns immediately.  The
system I use has a plug in ether debug board, so this probe is useful and
allows having a single image around.

 - a mac address set function outside of smc_open.  This proves useful when
boot happens with out the chip being touched but the kernel wants etherent.
The current Linux kernel drivers assume the MAC address is good so having it
set here saves messing around with the kernel driver.

 - all signed characters are now unsigned.  A previous patch was issued with
out changing all references.  This gets them all.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Wolfgang Denk | 1 Dec 2003 21:00
Picon
Picon
Favicon

Re: compiler for 8260

In message <DBF73ACB70D3D711A358000BDBACF5CE09D200 <at> ssmail1.skystream.com> you wrote:
> 
> 	I am trying to compile code for Ep8260 board. which compiler should
> i use for 8260 processor as its core is 6xx compatible core right. should i
> use a 8xx compiler or 6xx compiler.

You should use a 82xx compiler.

Best regards,

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
If it's working, the diagnostics say it's fine. If it's not  working,
the diagnostics  say  it's  fine.
              - A proposed addition to rules for realtime programming
Permalink | Reply | 0 comments |

Gmane