[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Timur Tabi]

On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:

   #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - 0x1000)
   #define CFG_ENV_SIZE		0x2000

This means that the environment is stored 0x1000 bytes before the start of u-boot.bin. 
Doesn't that mean that if the environment is larger than 0x1000 bytes, that it will 
overwrite the beginning of u-boot.bin whenever someone does a saveenv?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Timur Tabi]

Doesn't anyone have an answer to this question?

Timur Tabi wrote:
> On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:
> 
>    #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - 0x1000)
>    #define CFG_ENV_SIZE		0x2000
> 
> This means that the environment is stored 0x1000 bytes before the start of u-boot.bin. 
> Doesn't that mean that if the environment is larger than 0x1000 bytes, that it will 
> overwrite the beginning of u-boot.bin whenever someone does a saveenv?
> 


-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Jerry Van Baren]

Timur Tabi wrote:
> Doesn't anyone have an answer to this question?
> 
> Timur Tabi wrote:
>> On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:
>>
>>    #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - 0x1000)
>>    #define CFG_ENV_SIZE		0x2000
>>
>> This means that the environment is stored 0x1000 bytes before the start of u-boot.bin. 
>> Doesn't that mean that if the environment is larger than 0x1000 bytes, that it will 
>> overwrite the beginning of u-boot.bin whenever someone does a saveenv?

Looks like it to me. Looks like somebody increased the size without 
fixing the address offset to match.

Looks to me like it would be better defined:
#define CFG_ENV_SIZE		0x2000
#define CFG_ENV_ADDR		(CFG_MONITOR_BASE - CFG_ENV_SIZE)

The saving grace here is probably:
* For a RAMBOOT image, there isn't any incentive to save lots of stuff 
in the env since it (generally) disappears on a reboot and definitely 
disappears on a power cycle.

* On the PowerPC, at least, the first 12K of u-boot.bin is the HRCW and 
vectors which aren't used by a RAMBOOT image so overwriting them is a 
non-fatal error.

* 4K is fairly large for an env, so people probably don't run into the 
problem.

Best regards,
gvb

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <46535865.6060400@smiths-aerospace.com> you wrote:
>
> Looks to me like it would be better defined:
> #define CFG_ENV_SIZE		0x2000
> #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - CFG_ENV_SIZE)

No, this is broken as CFG_ENV_SIZE may be (and often actually is)
smaller than CFG_ENV_SECT_SIZE

> The saving grace here is probably:
> * For a RAMBOOT image, there isn't any incentive to save lots of stuff 
> in the env since it (generally) disappears on a reboot and definitely 
> disappears on a power cycle.

One could argue that a correctly  configured  ramboot  version  would
access  the  original  copy  of  the  environment  in flash. But such
discussion is void, as ramboot itself it not supported officially.

> * On the PowerPC, at least, the first 12K of u-boot.bin is the HRCW and 
> vectors which aren't used by a RAMBOOT image so overwriting them is a 
> non-fatal error.

Wrong. You may have timer and other interrupts,  so  overwriting  the
exception vectors is a Bad Thing (TM).


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A failure will not appear until a unit has passed final inspection.

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Timur Tabi]

Wolfgang Denk wrote:
> In message <46535865.6060400@smiths-aerospace.com> you wrote:
>> Looks to me like it would be better defined:
>> #define CFG_ENV_SIZE		0x2000
>> #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - CFG_ENV_SIZE)
> 
> No, this is broken as CFG_ENV_SIZE may be (and often actually is)
> smaller than CFG_ENV_SECT_SIZE

Why would that matter?  Does the environment need to be located on a sector boundary?

> One could argue that a correctly  configured  ramboot  version  would
> access  the  original  copy  of  the  environment  in flash. But such
> discussion is void, as ramboot itself it not supported officially.

My understanding of ramboot is that its sole purpose is to boot U-Boot when flash isn't 
working at all, so any ramboot-enabled U-Boot would never access anything on flash.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <46535B7B.2090903@freescale.com> you wrote:
>
> >> Looks to me like it would be better defined:
> >> #define CFG_ENV_SIZE		0x2000
> >> #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - CFG_ENV_SIZE)
> > 
> > No, this is broken as CFG_ENV_SIZE may be (and often actually is)
> > smaller than CFG_ENV_SECT_SIZE
> 
> Why would that matter?  Does the environment need to be located on a sector boundary?

Look at the code.

> > One could argue that a correctly  configured  ramboot  version  would
> > access  the  original  copy  of  the  environment  in flash. But such
> > discussion is void, as ramboot itself it not supported officially.
> 
> My understanding of ramboot is that its sole purpose is to boot U-Boot when flash isn't 
> working at all, so any ramboot-enabled U-Boot would never access anything on flash.

Other people had other ideas.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our business is run on trust.  We trust you will pay in advance.

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Timur Tabi]

Wolfgang Denk wrote:
> In message <46535B7B.2090903@freescale.com> you wrote:
>>>> Looks to me like it would be better defined:
>>>> #define CFG_ENV_SIZE		0x2000
>>>> #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - CFG_ENV_SIZE)
>>> No, this is broken as CFG_ENV_SIZE may be (and often actually is)
>>> smaller than CFG_ENV_SECT_SIZE
>> Why would that matter?  Does the environment need to be located on a sector boundary?
> 
> Look at the code.

Which code?  The environment isn't even located in flash, so what difference does it make 
if it's not on a sector boundary?  There aren't even any sectors!

>> My understanding of ramboot is that its sole purpose is to boot U-Boot when flash isn't 
>> working at all, so any ramboot-enabled U-Boot would never access anything on flash.
> 
> Other people had other ideas.

I don't recall reading any.  Can you tell what you're talking about?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <46535865.6060400@smiths-aerospace.com> you wrote:
>> Looks to me like it would be better defined:
>> #define CFG_ENV_SIZE		0x2000
>> #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - CFG_ENV_SIZE)
> 
> No, this is broken as CFG_ENV_SIZE may be (and often actually is)
> smaller than CFG_ENV_SECT_SIZE

In the case of RAMBOOT where the env is stored in RAM, the flash sector 
size is immaterial.  "But such discussion is void, as ramboot itself it 
not supported officially."

>> The saving grace here is probably:
>> * For a RAMBOOT image, there isn't any incentive to save lots of stuff 
>> in the env since it (generally) disappears on a reboot and definitely 
>> disappears on a power cycle.
> 
> One could argue that a correctly  configured  ramboot  version  would
> access  the  original  copy  of  the  environment  in flash. But such
> discussion is void, as ramboot itself it not supported officially.

Yup, but arguing minutia keeps geeks entertained.  ;-)

>> * On the PowerPC, at least, the first 12K of u-boot.bin is the HRCW and 
>> vectors which aren't used by a RAMBOOT image so overwriting them is a 
>> non-fatal error.
> 
> Wrong. You may have timer and other interrupts,  so  overwriting  the
> exception vectors is a Bad Thing (TM).

Beg to differ (granted, I was pretty loose in my description above).  If 
the env is being stored _before_ u-boot.bin, it means u-boot.bin is not 
being stored at location 0x00000000 thus _those_ vectors cannot be the 
ones actively being used by the processor.  They are the _source_ of the 
active vectors (copied to location 0 on relocation) but that is before 
they are *hypothetically* corrupted by the user creating 4K++ of env and 
then saving the env.

Obviously, the RAMBOOT u-boot.bin image cannot have more than 4K (+/-) 
of env variables built in or Very Bad Things would have happened during 
the link and/or execution.  "But such discussion is void, as ramboot 
itself it not supported officially."

> Best regards,
> 
> Wolfgang Denk

Best regards,
gvb

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Andy Fleming]

On 5/22/07, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
> Timur Tabi wrote:
> > Doesn't anyone have an answer to this question?

That's easy:  It's broken.  I sort of thought it was too obvious to
bother with a response.

> >
>
> The saving grace here is probably:
> * For a RAMBOOT image, there isn't any incentive to save lots of stuff
> in the env since it (generally) disappears on a reboot and definitely
> disappears on a power cycle.


I suspect what happened is that no one uses RAMBOOT, so no one noticed
when it broke.


>
> * On the PowerPC, at least, the first 12K of u-boot.bin is the HRCW and
> vectors which aren't used by a RAMBOOT image so overwriting them is a
> non-fatal error.

Woah, there.  On *some* PowerPC, the first 12k are HRCW.  On 85xx this
is not the case.  The low 256 bytes are for the version string and
some empty space.  Then we have _start.  The exception vectors (as
Wolfgang noted) are all in that space.  So it's not a problem as long
as you never hit a Decrementer exception...

suffice it to say, I would accept any patch which fixed this.  But
left to my own devices, I don't anticipate fixing this anytime soon.


>
> * 4K is fairly large for an env, so people probably don't run into the
> problem.
>
> Best regards,
> gvb
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Timur Tabi]

Andy Fleming wrote:
> On 5/22/07, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
>> Timur Tabi wrote:
>> > Doesn't anyone have an answer to this question?
> 
> That's easy:  It's broken.  I sort of thought it was too obvious to
> bother with a response.

When something is obviously broken and yet prevalent, it makes me think I might be missing 
something.  In this case, it appears I'm not.

> suffice it to say, I would accept any patch which fixed this.  But
> left to my own devices, I don't anticipate fixing this anytime soon.

It's on my to-do list.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <46535F2D.80805@freescale.com> you wrote:
>
> When something is obviously broken and yet prevalent, it makes me think I might be missing 
> something.  In this case, it appears I'm not.

Prevalent? 16 out of 354 configurations, and all of the same breed?

That's a pretty isolated phenomenon tome.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
How come everyone's going so slow if it's called rush hour?

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Timur Tabi]

Wolfgang Denk wrote:
> In message <46535F2D.80805@freescale.com> you wrote:
>> When something is obviously broken and yet prevalent, it makes me think I might be missing 
>> something.  In this case, it appears I'm not.
> 
> Prevalent? 16 out of 354 configurations, and all of the same breed?

It's prevalent among Freescale 8xxx-based boards, which is good enough for me.  Since I'm 
not familiar with the other architectures, I can only use quirks in the 8xxx code as a 
basis for anything.  And that's why I post questions like this to the mailing list, so 
that I can see if anyone with more experience can shed some light.  Unfortunately, I 
occasionally get flamed for it.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <46535464.6090206@freescale.com> you wrote:
> Doesn't anyone have an answer to this question?

Maybe nobody cares? It's an officially unsupported feature anyway.

> Timur Tabi wrote:
> > On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:

Let's put this straight: it is not "a lot of boards", it's just 16
boards - less than 5%:

MPC8313ERDB       MPC8360EMDS       MPC8641HPCN       TQM834x
MPC832XEMDS       MPC8540ADS        PM854             sbc8349
MPC8349EMDS       MPC8540EVAL       PM856             sbc8560
MPC8349ITX        MPC8560ADS        SBC8540           stxgp3

If you look closer, you can see that it's only 83xx,  85xx  and  86xx
systems.  Guess  where  most of the responsible board maintainers are
sitting? And who the responsible custodians are?

> >    #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - 0x1000)
> >    #define CFG_ENV_SIZE		0x2000

Of course this is broken and should always be written as 

	#define CFG_ENV_ADDR (CFG_MONITOR_BASE-CFG_ENV_SECT_SIZE)

instead.

> > This means that the environment is stored 0x1000 bytes before the start of u-boot.bin. 
> > Doesn't that mean that if the environment is larger than 0x1000 bytes, that it will 
> > overwrite the beginning of u-boot.bin whenever someone does a saveenv?

I suggest you raise the  issue  with  the  board  maintainers  and/or
custodians. Maybe you simply remove all this broken ramboot support.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You got to learn three things. What's  real,  what's  not  real,  and
what's the difference."           - Terry Pratchett, _Witches Abroad_

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Andy Fleming]

On 5/22/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <46535464.6090206@freescale.com> you wrote:
> > Doesn't anyone have an answer to this question?
>
> Maybe nobody cares? It's an officially unsupported feature anyway.

I suspect that's why we've not heard any complaints

>
> > Timur Tabi wrote:
> > > On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:
>
> Let's put this straight: it is not "a lot of boards", it's just 16
> boards - less than 5%:
>
> MPC8313ERDB       MPC8360EMDS       MPC8641HPCN       TQM834x
> MPC832XEMDS       MPC8540ADS        PM854             sbc8349
> MPC8349EMDS       MPC8540EVAL       PM856             sbc8560
> MPC8349ITX        MPC8560ADS        SBC8540           stxgp3
>
> If you look closer, you can see that it's only 83xx,  85xx  and  86xx
> systems.  Guess  where  most of the responsible board maintainers are
> sitting? And who the responsible custodians are?


Yeah, we let this slip in to the first 85xx board (It was useful for
bring-up, when we didn't have working Flash support).  And it's fairly
straightforward to see that the config files have just been copied
from the original MPC8540ADS, and modified.

Anyone who wants to eliminate the RAMBOOT stuff has *my* blessing.
It's just way down my priority list for actually doing.

>
> I suggest you raise the  issue  with  the  board  maintainers  and/or
> custodians. Maybe you simply remove all this broken ramboot support.


Works for me.  Who's got a patch.  ;)

Andy

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Tue, May 22, 2007 at 11:00:57PM +0200, Wolfgang Denk wrote:
> I suggest you raise the  issue  with  the  board  maintainers  and/or
> custodians. Maybe you simply remove all this broken ramboot support.

Shall I read it a general rule? i.e. remove support for at91rm9200dk
Atmel's reference design broken since 04 Apr 2005?

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> On Tue, May 22, 2007 at 11:00:57PM +0200, Wolfgang Denk wrote:
>> I suggest you raise the  issue  with  the  board  maintainers  and/or
>> custodians. Maybe you simply remove all this broken ramboot support.
> 
> Shall I read it a general rule? i.e. remove support for at91rm9200dk
> Atmel's reference design broken since 04 Apr 2005?
> 
> Best regards,
> ladis
> 

Things are broken, because Wolfgang refuses patches fixing problems on AT91 on principle.
Removing support will cause more work for people
because the existing patches to make things work
will have to be modified...

What is the point of sabotaging others peoples efforts???

Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Wed, May 23, 2007 at 12:48:20PM +0200, Ulf Samuelsson wrote:
> Things are broken, because Wolfgang refuses patches fixing problems on AT91 on principle.
> Removing support will cause more work for people
> because the existing patches to make things work
> will have to be modified...

Wolfgang is waiting for custodian to comment on patch. So far nothing
happened. Please note that I'm the last one who wants to see support of
this board removed. Also I'm all for applying patches you send to the
mailing list (that serie 1,2,3,4,6,7,10,24) except for 24.noflash
which seems a bit hackish (and yes I run into the very same problem this
patch is trying to solve recently). If there is anything I can do to
help them to get applied, just let me know.

> What is the point of sabotaging others peoples efforts???

Removing non working code makes whole codebase cleaner. Sabotage is
leaving non working code in repository without any will to at least
consider applying patches... Anyway, who is responsible for AT91 code?

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

 On Wed, May 23, 2007 at 12:48:20PM +0200, Ulf Samuelsson wrote:
>> Things are broken, because Wolfgang refuses patches fixing problems on AT91 on principle.
>> Removing support will cause more work for people
>> because the existing patches to make things work
>> will have to be modified...
> 
> Wolfgang is waiting for custodian to comment on patch. So far nothing
> happened. Please note that I'm the last one who wants to see support of
> this board removed. Also I'm all for applying patches you send to the
> mailing list (that serie 1,2,3,4,6,7,10,24) except for 24.noflash
> which seems a bit hackish (and yes I run into the very same problem this
> patch is trying to solve recently). If there is anything I can do to
> help them to get applied, just let me know.
> 
>> What is the point of sabotaging others peoples efforts???
> 

> Removing non working code makes whole codebase cleaner. Sabotage is
> leaving non working code in repository without any will to at least
> consider applying patches... Anyway, who is responsible for AT91 code?
> 

I think the AT91 group submitted the at91rm9200dk support.
All following patches has been rejected.
They are fed up with lack of response, has decided not to waste time time on this
until the attitude is changed.

I tried to resubmit, but since Grant and Wolfgang has come to the conclusion
that sometimes memory is not memory I see no possibility to 
overcome difference.

The correct approach is to fix the support, and I believe Grant started
the debate by saying that he wanted to fix it.
I have not seen any result of this.


> Best regards,
> ladis

Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <007301c79d3a$37b63320$f22ab10a@atmel.com> you wrote:
>
> I tried to resubmit, but since Grant and Wolfgang has come to the
> conclusion
> that sometimes memory is not memory I see no possibility to 
> overcome difference.

Memory is always memory. Serially attached devices are NOT memory.

But IIRC this is only one part of your patches. There are other parts
that have not been disputed.

> The correct approach is to fix the support, and I believe Grant started
> the debate by saying that he wanted to fix it.
> I have not seen any result of this.

Maybe you could just submit the other parts of your fixes in the
meantime?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One difference between a man and a machine is that a machine is quiet
when well oiled.

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> In message <007301c79d3a$37b63320$f22ab10a@atmel.com> you wrote:
>>
>> I tried to resubmit, but since Grant and Wolfgang has come to the
>> conclusion
>> that sometimes memory is not memory I see no possibility to 
>> overcome difference.
> 
> Memory is always memory. Serially attached devices are NOT memory.

That is _your_ definition of memory, others like "Webster Dictionary" say:

"Memory: a device (as a chip) or a component of a device in which information especially for a computer can be inserted and stored and from which it may be extracted when wanted; especially : RAM"

You add an extra requirement that memory must be randomly addressable over a parallel bus.
This view is uncompatible with Websters dictionary which does not pose such restrictions.
Furthermore, everyone designing flash memories, believe that serial flash memories
are memories.

You have made your decision here, and I have to accept that, but 
you are then trying to get *me* to make the changes you want,
and I really have no incentive to do that and will leave that to others.

> But IIRC this is only one part of your patches. There are other parts
> that have not been disputed.
> 
>> The correct approach is to fix the support, and I believe Grant started
>> the debate by saying that he wanted to fix it.
>> I have not seen any result of this.
> 
> Maybe you could just submit the other parts of your fixes in the
> meantime?

I have submitted one, and will submit more if that gets accepted,

The remainder are basically "board/<board>/*" files and
"cpu/arm926ejs/at91sam926x/*" files.
None of these patches will result in anything useful for U-boot
since the dataflash support will be broken and no board will
work without dataflash. - ALL boards will be broken.

Since "dangling" patches are not wanted, why would any patch get accepted.



> Best regards,
> 
> Wolfgang Denk
> 


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                ftp://at91dist:distrib at 81.80.104.162/

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Wed, May 23, 2007 at 06:19:21PM +0200, Ulf Samuelsson wrote:
> > In message <007301c79d3a$37b63320$f22ab10a@atmel.com> you wrote:
> >>
> >> I tried to resubmit, but since Grant and Wolfgang has come to the
> >> conclusion that sometimes memory is not memory I see no possibility
> >> to overcome difference.
> >
> > Memory is always memory. Serially attached devices are NOT memory.
>
> That is _your_ definition of memory, others like "Webster Dictionary"
> say:
> 
> "Memory: a device (as a chip) or a component of a device in which
> information especially for a computer can be inserted and stored and
> from which it may be extracted when wanted; especially : RAM"
> 
> You add an extra requirement that memory must be randomly addressable
> over a parallel bus.  This view is uncompatible with Websters
> dictionary which does not pose such restrictions.  Furthermore,
> everyone designing flash memories, believe that serial flash memories
> are memories.

That belive has nothing to do with software interface design. While you
pretend serial flash memory is somehow mapped into procesor address
space, others have different ideas. "Webster Dictionary" uses largest
common denominator so its definition applies to hard discs as well.
Do we pretend hard disc content is mapped over IDE or SCSI bus into
CPU address space?

> You have made your decision here, and I have to accept that, but you
> are then trying to get *me* to make the changes you want, and I really
> have no incentive to do that and will leave that to others.

Then I'm voluntering to do that work. There is one issue left. The
interface. I remember few almost endless debates about this topic, but
no conclusion.

Lets dive into archives.

In this thread most of possible solutions were developed. Without
conclusion.
Subject: Atmel DataFlash hooks.
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/25983

And this is another very interesting thread:
Subject: [PATCH] DataFlash for AT91RM9200DK board
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/9175
It contains quite interesting part which is worth to repeat there
(by Wolfgang Denk, 2003-06-04)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> In our case, we use it to store and boot an image of linux(the dataflash
> contains the linux zImage and the ramdisk).
> This dataflash can be used also for a filesystem.

In this case I think we should offer an interface which looks\
to the user like mmeory.

Instead of providing separate commands to read and  write  from  such
"memory" I think we should integrate this into the existing code.

For  example,  writing  to  "normal"  flash  memory  is  an  implicit
operation  to the "cp" (copy) command when it detects that the target
address is in flash memory.

The same should be done for dataflash.

OK, with "normal" flash memory we don't  have  to  special-case  read
accesses  like  used  by  "md" or "bootm" commands - where in case of
dataflash such handling will be necessary.

But especially if you boot Linux from dataflash it seems more logical
to me to use "bootm" directly instead of  using  "dataflash  read"  +
"bootm" in separate steps.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

That makes clear reasons behind Ulf's statement and also shows that not
all decisions are good ones.

If anyone feels need to fix u-boot's dataflash support, then please
either lets continue in more than 16 weeks old debate in 'Atmel
DataFlash hooks' thread or spawn new one.

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

Dear Ladislav,

in message <20070524121048.GA6516@michl.2n.cz> you wrote:
>
> And this is another very interesting thread:
> Subject: [PATCH] DataFlash for AT91RM9200DK board
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/9175
> It contains quite interesting part which is worth to repeat there
> (by Wolfgang Denk, 2003-06-04)

I don't have words to express how much I repent these words.

When I wrote this, I had no  idea  what  DataFlash  is  and  that  it
actually uses a serial interface. It would be lame if I tried to come
up ith the "little time" excuse, because it does not help to undo the
damage done then.

> > In our case, we use it to store and boot an image of linux(the dataflash
> > contains the linux zImage and the ramdisk).
> > This dataflash can be used also for a filesystem.
> 
> In this case I think we should offer an interface which looks\
> to the user like mmeory.

This was  a  major  misapprehension,  and  I  formally  apologize  to
everybody who suffered or still suffers from the consequences.

> That makes clear reasons behind Ulf's statement and also shows that not
> all decisions are good ones.

Right. This was definitely a bad one.

> If anyone feels need to fix u-boot's dataflash support, then please
> either lets continue in more than 16 weeks old debate in 'Atmel
> DataFlash hooks' thread or spawn new one.

DataFlash is much more similar to NAND flash than it is to NOR flash
or RAM. 

IMHO a pretty good summary of the last state of the previous thread
can be found here:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/26147

In short:

* the cmd_mem hooks should be removed and replaced by a new interface
* the new interface will probably be similar to the NAND interface
* both the process for the migration and the new command format
  need to be discussed
* there is no intention to remove functionality, nor to sabotage
  anybody, but there is pending cleanup that needs to get done sooner
  or later

During the transition perion, it is IMHO not a good idea to add more
code to the old interface because this will just increase the amount
of cleanup work that will be needed later; instead, efforts should be
put in helping to define, implement and test the new interface.

Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The algorithm to do that is extremely nasty. You might want  to  mug
someone with it."                   - M. Devine, Computer Science 340

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Thu, May 24, 2007 at 03:03:39PM +0200, Wolfgang Denk wrote:
> IMHO a pretty good summary of the last state of the previous thread
> can be found here:
> 
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/26147
> 
> In short:
> 
> * the cmd_mem hooks should be removed and replaced by a new interface
> * the new interface will probably be similar to the NAND interface

Perhaps it would make sense build it on top of SPI interface. This way
one could read registers of other SPI peripherals (MMC cards etc).
I'm not sure how useful it can be. Anyway, implementing that for
dataflash seems pretty straightforward, so I'll code it.

> * both the process for the migration and the new command format
>   need to be discussed
> * there is no intention to remove functionality, nor to sabotage
>   anybody, but there is pending cleanup that needs to get done sooner
>   or later

It would be good to get at45.c patch merged first. It will make
maintaining changes much easier.

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

>> >
>> > Memory is always memory. Serially attached devices are NOT memory.
>>
>> That is _your_ definition of memory, others like "Webster Dictionary"
>> say:
>> 
>> "Memory: a device (as a chip) or a component of a device in which
>> information especially for a computer can be inserted and stored and
>> from which it may be extracted when wanted; especially : RAM"
>> 
>> You add an extra requirement that memory must be randomly addressable
>> over a parallel bus.  This view is uncompatible with Websters
>> dictionary which does not pose such restrictions.  Furthermore,
>> everyone designing flash memories, believe that serial flash memories
>> are memories.
> 
> That belive has nothing to do with software interface design. While you
> pretend serial flash memory is somehow mapped into procesor address
> space, others have different ideas. "Webster Dictionary" uses largest
> common denominator so its definition applies to hard discs as well.
> Do we pretend hard disc content is mapped over IDE or SCSI bus into
> CPU address space?

Not in U-boot but in very efficient databases, the virtual memory is used to directly map
to hard disks since this is much more efficient than file access.
This is one of the main reasons to move to 64 bit virtual addressing

my primary concern is ease of use, and I am pretty sure that 
any new interface will result in more typing than the old interface.

Just the thought of having to type 
"spi write" or 
"dataflash write" 

instead of 

"cp.b"

sends shudder down my spine...

If people agreed that we change the memory interface from "cp.b" to

"memory write"

then I would have more sympathy for the change.

Any interface to dataflash would need the following operations:

* move from sdram to dataflash (with optional checksum write & byte granularity)
* move from dataflash to sdram (with optional checksum check & byte granularity)
* compare dataflash to sdram
* list dataflash contents
* fill dataflash
* modify dataflash (with byte granularity)
* erase dataflash (byte and partition)
* enable/disable write protection of dataflash partition
* print dataflash chip info

I see no reason to compare two dataflash areas and to compare two dataflash areas.

It should be possible to stored the environment in dataflash

The partitioning of the flash needs to take into account that 
the dataflash pages are not 2^n, they are 2^n + some small amount.
The 256 page sectors should also be taken into account.
The current partitioning is totally screwed for a linux-2.6 kernel.
It would be good to be able to change the partition information dynamically
so you can grow/shrink the linux-kernel size.

Possibly the pagesize should be migrated into the environment




[snip]


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                ftp://at91dist:distrib at 81.80.104.162/

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <01f401c79e40$5e938450$0302a8c0@atmel.com> you wrote:
>
> Any interface to dataflash would need the following operations:

Good. We're back on a technical level and can discuss potential
implementations.

Let me try to reformulate yur suggestions a bit, trying  tomap  these
into  my  idea  of  a  possible  interface  (just  as base for future
discussion):

> * move from sdram to dataflash (with optional checksum write & byte
> granularity)

* Copy from memory to dataflash

  I see no reason why we should restrict the source of  the  copy  to
  RAM.  Also,  we should use the term "copy" as "move" to me includes
  the operation of removing/erasing the source of the data.

  What exactly do you mean by "checksum write"?  The  currently  used
  "cp.b" interface doesn't do anything like this either, or does it?

> * move from dataflash to sdram (with optional checksum check & byte
> granularity)

* Copy from dataflash to memory.

  Same remars as above.

> * compare dataflash to sdram

* That would be a two step procedure, like currently used for other
  storage devices:

  - Copy from dataflash to memory
  - compare two memory areas

  No new command needed.

> * list dataflash contents

  What exactly do you mean here? Do you have any such function
  currently?

> * fill dataflash

* That would be a two step procedure:
  - fill memory area (RAM)
  - copy from memory to dataflash

  No new command needed.

> * modify dataflash (with byte granularity)

* That would be a three step procedure:

  - Copy from dataflash to memory
  - modify memory
  - copy from memory to dataflash

  No new command needed.

> * erase dataflash (byte and partition)

  OK.

> * enable/disable write protection of dataflash partition

  OK.

> * print dataflash chip info

  OK.

> I see no reason to compare two dataflash areas and to compare two
> dataflash areas.

Neither do I, as it boild down to the elementary functions listed
above: copy to memory and compare in memory.

> It should be possible to stored the environment in dataflash

Agreed.

> It would be good to be able to change the partition information
> dynamically
> so you can grow/shrink the linux-kernel size.

The mtdparts command should support dataflash devices, too.

> Possibly the pagesize should be migrated into the environment

What do you mean by that?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Randal said it would be tough to do in sed. He didn't say  he  didn't
understand  sed.  Randal  understands sed quite well. Which is why he
uses Perl. :-)         - Larry Wall in <7874@jpl-devvax.JPL.NASA.GOV>

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> In message <01f401c79e40$5e938450$0302a8c0@atmel.com> you wrote:
>>
>> Any interface to dataflash would need the following operations:
> 
> Good. We're back on a technical level and can discuss potential
> implementations.
> 
> Let me try to reformulate yur suggestions a bit, trying  tomap  these
> into  my  idea  of  a  possible  interface  (just  as base for future
> discussion):
> 
>> * move from sdram to dataflash (with optional checksum write & byte
>> granularity)
> 
> * Copy from memory to dataflash
> 
>  I see no reason why we should restrict the source of  the  copy  to
>  RAM.  Also,  we should use the term "copy" as "move" to me includes
>  the operation of removing/erasing the source of the data.
> 
>  What exactly do you mean by "checksum write"?  The  currently  used
>  "cp.b" interface doesn't do anything like this either, or does it?
> 

No but a way to common error is that the kernel is too large to fit into
its allocated area and when the file system is written it overwwrites the end
of the kernel.
In my branch, I can set an environment variable crccheck=1
and if set, any cp.b to dataflash will add a checksum at the end.
Any cp.b from dataflash will again compute the checksum
and compare vs the checksum at the end.

Saves me a lot of confusing linux boot errors.

>> * move from dataflash to sdram (with optional checksum check & byte
>> granularity)
> 
> * Copy from dataflash to memory.
> 
>  Same remars as above.
> 
>> * compare dataflash to sdram
> 
> * That would be a two step procedure, like currently used for other
>  storage devices:
> 
>  - Copy from dataflash to memory
>  - compare two memory areas

If I wanted to wear down my fingers by typing a lot of things,
I would have choosen a career as a COBOL programmer.

Your suggestion has the unwanted side effect that you destroy the SDRAM
in the process, and you have to keep in mind where you put intermediate copies.

Since dataflash sectors are 256 kB, and you should avoid putting linux/rootfs
in the same sector as u-boot, code size is of much less importance than
ease of use.

It is very important to reduce typing to a minimum.

Having to do 2-3 commands to do what can be done by one command
and complicating the user experience in the process, is simply not acceptable.

>  No new command needed.
> 
>> * list dataflash contents
> 
>  What exactly do you mean here? Do you have any such function
>  currently?
> 

yes

>> * fill dataflash
> 
> * That would be a two step procedure:
>  - fill memory area (RAM)
>  - copy from memory to dataflash
> 

>  No new command needed.

See above, ease of use, is much more important than code size.

>> * modify dataflash (with byte granularity)
> 
> * That would be a three step procedure:
> 
>  - Copy from dataflash to memory
>  - modify memory
>  - copy from memory to dataflash
> 
>  No new command needed.
> 
>> * erase dataflash (byte and partition)
> 
>  OK.
> 
>> * enable/disable write protection of dataflash partition
> 
>  OK.
> 
>> * print dataflash chip info
> 
>  OK.
> 
>> I see no reason to compare two dataflash areas and to compare two
>> dataflash areas.
> 
> Neither do I, as it boild down to the elementary functions listed
> above: copy to memory and compare in memory.
> 
>> It should be possible to stored the environment in dataflash
> 
> Agreed.
> 
>> It would be good to be able to change the partition information
>> dynamically
>> so you can grow/shrink the linux-kernel size.
> 
> The mtdparts command should support dataflash devices, too.
> 
>> Possibly the pagesize should be migrated into the environment
> 
> What do you mean by that?
> 

The pagesize of the dataflash varies between 264,528,1056 bytes depending on chip.
It might be of interest to know this in a script.

> Best regards,
> 

It should be possible to remove any code accessing parallel flash,
so the memory commands only access SDRAM.
Many boards do not have any parallel flash, and this code will just bloat the binary.

> Wolfgang Denk
> 
> -- 


Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <030501c79e4e$862cf740$0302a8c0@atmel.com> you wrote:
>
> >  What exactly do you mean by "checksum write"?  The  currently  used
> >  "cp.b" interface doesn't do anything like this either, or does it?
> 
> No but a way to common error is that the kernel is too large to fit into
> its allocated area and when the file system is written it overwwrites
> the end
> of the kernel.
> In my branch, I can set an environment variable crccheck=1
> and if set, any cp.b to dataflash will add a checksum at the end.
> Any cp.b from dataflash will again compute the checksum
> and compare vs the checksum at the end.

Why would that be needed? The U-Boot image itself is protected  by  a
CRC32  checksum  (by  two,  actually), so any such corruption will be
detected automatically whenever you try to boot such an image.

> Saves me a lot of confusing linux boot errors.

Of course checksums are very useful - but we already have them?

> > * That would be a two step procedure, like currently used for other
> >  storage devices:
> > 
> >  - Copy from dataflash to memory
> >  - compare two memory areas
> 
> If I wanted to wear down my fingers by typing a lot of things,
> I would have choosen a career as a COBOL programmer.

U-Boot follows good old Unix philosophy here: prvode small and simple
tools that implemnt just one task, but this reliably and efficiently,
and provide ways to combine these tools easily to bigger  things.  Of
course  it  is  trivial to combine these steps into one "command" for
the user.

> Your suggestion has the unwanted side effect that you destroy the SDRAM
> in the process, and you have to keep in mind where you put intermediate
> copies.

Well, the same is stru for your current  implementation,  which  also
needs  some buffers in RAM. The only difference is size and locatioon
of the buffers.  U-Boot  usually  remembers  the  "last  used"  image
address,  you  normally you don't need to remember much. If in doubt,
use variables.

> Since dataflash sectors are 256 kB, and you should avoid putting
> linux/rootfs
> in the same sector as u-boot, code size is of much less importance than
> ease of use.

Primarily it's not a question of code size, but of interfaces.

> It is very important to reduce typing to a minimum.

This is not one of my primary targets. It's not even very high on  my
list.

> >> * list dataflash contents
> > 
> >  What exactly do you mean here? Do you have any such function
> >  currently?
> 
> yes

What exactly does it do?

> It should be possible to remove any code accessing parallel flash,
> so the memory commands only access SDRAM.

Agreed.

> Many boards do not have any parallel flash, and this code will just
> bloat the binary.

"Many" is probably not correct if you look at the total of nearly 400
board configurations in the public U-Boot  tree.  But  I  agree  that
support  for  NOR  flash  should be configurable like other features,
too.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Stefan Roese]

Hi Ulf,

On Thursday 24 May 2007, Ulf Samuelsson wrote:
> >> * compare dataflash to sdram
> >
> > * That would be a two step procedure, like currently used for other
> >  storage devices:
> >
> >  - Copy from dataflash to memory
> >  - compare two memory areas
>
> If I wanted to wear down my fingers by typing a lot of things,
> I would have choosen a career as a COBOL programmer.

We also have board with NAND FLASH only and the number of those boards will 
grow in the near future. The NAND command interface of course need a little 
more typing, but I always configure a few environment variables to update the 
images in the NAND FLASH. Something like:

=> setenv nload 'tftp 200000 board/u-boot.bin'
=> setenv nupdate 'nand erase 0 40000;nand write 200000 0 40000'
=> setenv nupd 'run nload nupdate'

A simple "run nupd" will update the image for me then. Not much typing 
involved.

BTW: I do the same with "normal" NOR FLASH images too, so it always boils down 
to some env variable commands. And if you have defined those variables in the 
default env variables, then all "users" can access them right away.

But I understand that your main concern is the *change* of the dataflash user 
interface. Yes, this is a problem and we can't really solve it. But a README 
and some env variables might make this change easier for the "users".

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

Hi (and thanks for starting this discussion again),

On Fri, May 25, 2007 at 07:37:53AM +0200, Stefan Roese wrote:
> We also have board with NAND FLASH only and the number of those boards will 
> grow in the near future. The NAND command interface of course need a little 
> more typing, but I always configure a few environment variables to update the 
> images in the NAND FLASH. Something like:
> 
> => setenv nload 'tftp 200000 board/u-boot.bin'
> => setenv nupdate 'nand erase 0 40000;nand write 200000 0 40000'
> => setenv nupd 'run nload nupdate'

Yes, yes :-) Here I agree with Wolfgand and Stefan. U-Boot should
provide commands which reflect principle of device without any
abstraction. Knowing principle means usually less bad surprises coming
out from some hidden abstraction implementation details. That's good for
power users.

Then we can use scripts in enviroment variables to save typing.
This also gives wider range of commands built from 'primitives' Wolfgang
described earlier. And typing 'printenv nupdate' gives a clue what this
command actually does.

And for my grandfather it is possible to hide command line completely:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27992

> A simple "run nupd" will update the image for me then. Not much typing 
> involved.
> 
> BTW: I do the same with "normal" NOR FLASH images too, so it always boils down 
> to some env variable commands. And if you have defined those variables in the 
> default env variables, then all "users" can access them right away.

If we implement mtdparts command on dataflash, user can even do:
nand erase kernel0
nand write 0x10400000 kernel0 $filesize

This way you can copy to partition by its symbolic name (you do not need
to remember offset) and this command also doesn't allow you to copy more
than partition size. Partitioning is then done at one place respecting
sector size and other constrains and it is also passed to kernel.

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> On Wed, May 23, 2007 at 12:48:20PM +0200, Ulf Samuelsson wrote:
>> Things are broken, because Wolfgang refuses patches fixing problems on AT91 on principle.
>> Removing support will cause more work for people
>> because the existing patches to make things work
>> will have to be modified...
> 
> Wolfgang is waiting for custodian to comment on patch. So far nothing
> happened. Please note that I'm the last one who wants to see support of
> this board removed. Also I'm all for applying patches you send to the
> mailing list (that serie 1,2,3,4,6,7,10,24) except for 24.noflash
> which seems a bit hackish (and yes I run into the very same problem this
> patch is trying to solve recently). If there is anything I can do to
> help them to get applied, just let me know.
> 
>> What is the point of sabotaging others peoples efforts???
> 
> Removing non working code makes whole codebase cleaner. Sabotage is
> leaving non working code in repository without any will to at least
> consider applying patches... Anyway, who is responsible for AT91 code?
> 
> Best regards,
> ladis
> 

 
Instead of wasting your time with the mainstream u-boot 
for the AT91, you could try out my patched u-boot-1.2.0-atmel at
ftp://at91supp:support at 81.80.104.162/ -> AT91 Third Party -> Linux_Host -> Source

I have a working dataflash support for most Atmel chips there (board = at91rm9200df).
It also gets automatically built by the "buildroot" at the same location.

If you have any suggestions/patches, then I would be happy to add that.

Best Regards
Ulf Samuelsson


> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Wed, May 23, 2007 at 02:59:11PM +0200, Ulf Samuelsson wrote:
> Instead of wasting your time with the mainstream u-boot 
> for the AT91, you could try out my patched u-boot-1.2.0-atmel at
> ftp://at91supp:support at 81.80.104.162/ -> AT91 Third Party -> Linux_Host -> Source

To be honest, mainstream u-boot works pretty well for me. I'm even using
it on board without NOR flash (only serial and NAND) :-) It is just not
as nice and featurefull as it could be.

> I have a working dataflash support for most Atmel chips there (board = at91rm9200df).
> It also gets automatically built by the "buildroot" at the same location.

I'm prefering PTXdist which is building toolchain, rootfs and u-boot as
well and is not uClibc centric...

> If you have any suggestions/patches, then I would be happy to add that.

I'll look at your patches and try to split them to smaller chunks...
Lets see if that's posible.

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> On Wed, May 23, 2007 at 02:59:11PM +0200, Ulf Samuelsson wrote:
>> Instead of wasting your time with the mainstream u-boot 
>> for the AT91, you could try out my patched u-boot-1.2.0-atmel at
>> ftp://at91supp:support at 81.80.104.162/ -> AT91 Third Party -> Linux_Host -> Source
> 
> To be honest, mainstream u-boot works pretty well for me. I'm even using
> it on board without NOR flash (only serial and NAND) :-) It is just not
> as nice and featurefull as it could be.
> 
>> I have a working dataflash support for most Atmel chips there (board = at91rm9200df).
>> It also gets automatically built by the "buildroot" at the same location.
> 
> I'm prefering PTXdist which is building toolchain, rootfs and u-boot as
> well and is not uClibc centric...
> 

Is that part of mainstream PTXdist, or do you apply your own patches?

My buildroot will build: at91-bootstrap, u.boot, linux, rootfs and scripts
for u-boot tying things together, but is of course uClibc centric.

>> If you have any suggestions/patches, then I would be happy to add that.
> 
> I'll look at your patches and try to split them to smaller chunks...
> Lets see if that's posible.
> 
In the  ftp location, there is only a tarball.

I write a small utility which splits the diff into patches which will handle each file.
Unfortunately, the way U-boot is structured, you will get files (like $(TOPDIR)/Makefile)
which contains the result of many patches.
I would prefer a structure where a Makefile fragment for the board is inside
the board/<board> directory and the Makefile includes "board/*/*.mk".
Much easier to add boards this way without beeing intrusive.


> Best regards,
> ladis


Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Wed, May 23, 2007 at 06:05:31PM +0200, Ulf Samuelsson wrote:
> Is that part of mainstream PTXdist, or do you apply your own patches?

I'm applying my own patches directly to PTXdist's svn ;-)

> My buildroot will build: at91-bootstrap, u.boot, linux, rootfs and scripts
> for u-boot tying things together, but is of course uClibc centric.

PTXdist does the same for me. Also builds toolchain. Those two projects
does basicaly the same, but PTXdist design seems better for me. And
because it is matter of personal preferences and of topic here, you are
welcome to continue debate or ask questions on PTXdist mailing list.
http://www.pengutronix.de/software/ptxdist/index_en.html

> >> If you have any suggestions/patches, then I would be happy to add that.
> > 
> > I'll look at your patches and try to split them to smaller chunks...
> > Lets see if that's posible.
> > 
> In the  ftp location, there is only a tarball.
> 
> I write a small utility which splits the diff into patches which will handle each file.
> Unfortunately, the way U-boot is structured, you will get files (like $(TOPDIR)/Makefile)
> which contains the result of many patches.

I did my best to check patches you sent to mailing list, tried to
address suggestions (if any) and sent again to custodians. Lets see what
happens. In case things move on I will continue stealing code from your
ftp, verify on boards I have here and try to push in.

> I would prefer a structure where a Makefile fragment for the board is inside
> the board/<board> directory and the Makefile includes "board/*/*.mk".
> Much easier to add boards this way without beeing intrusive.

That seems reasonable. But that rule would have to be more complex to
support for example board/atmel/atstk1000/

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> I did my best to check patches you sent to mailing list, tried to
> address suggestions (if any) and sent again to custodians. Lets see what
> happens. In case things move on I will continue stealing code from your
> ftp, verify on boards I have here and try to push in.
> 

You are welcome.

>> I would prefer a structure where a Makefile fragment for the board is inside
>> the board/<board> directory and the Makefile includes "board/*/*.mk".
>> Much easier to add boards this way without beeing intrusive.
> 
> That seems reasonable. But that rule would have to be more complex to
> support for example board/atmel/atstk1000/
> 

Obviously if Atmel had control over the board/atmel directory
the board/atmel/atmel.mk fragment would include
    board/atmel/*/*.mk

Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> 
> PTXdist does the same for me. Also builds toolchain. Those two projects
> does basicaly the same, but PTXdist design seems better for me. And
> because it is matter of personal preferences and of topic here, you are
> welcome to continue debate or ask questions on PTXdist mailing list.
> http://www.pengutronix.de/software/ptxdist/index_en.html
> 

Digging into OpenEmbedded at the moment, so I think I'll wait...

Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <002601c79d29$4da6de70$3125b10a@atmel.com> you wrote:
>
> Things are broken, because Wolfgang refuses patches fixing problems on
> AT91 on principle.

Nonsense.

Fix the known issues with your patches, submit these and get them
accepted by the ARM custodian. If they don't break general U-Boot
design criteria I will then just pull from the ARM repo.

But please fix the issues.

> Removing support will cause more work for people
> because the existing patches to make things work
> will have to be modified...
> 
> What is the point of sabotaging others peoples efforts???

Instead of overwehemlimng everybody with a series of monster patches
that change change U-Boot inside out you could try submitting small,
isolated patches that fix the real problems step by step. If your
patches are orthogonal, you could get at lest 90% of your stuff merged
without any discussion, and then we could focus oin the remaining
difficult parts.

Just because others don't agree with you does not mean  the  sabotage
you. Robert Schwebel and others tried to explain this to you before.

If you cannot advance with brute force, try using diplomacy  instead.
Just insulting others is definitely not helpful.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Either one of us, by himself, is expendable.  Both of us are not.
	-- Kirk, "The Devil in the Dark", stardate 3196.1

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> In message <002601c79d29$4da6de70$3125b10a@atmel.com> you wrote:
>>
>> Things are broken, because Wolfgang refuses patches fixing problems on
>> AT91 on principle.
> 
> Nonsense.

Let me rephrase this in a less sloppy manner.

Things are broken, because Wolfgang refuses [some critical] patches fixing problems on
AT91 on principle. - Dataflash should not be treated as random access memory.
 
> Fix the known issues with your patches, submit these and get them
> accepted by the ARM custodian. If they don't break general U-Boot
> design criteria I will then just pull from the ARM repo.
> 
> But please fix the issues.

I am not going to develop new user interface for the dataflash
because I do not agree that it is neccessary to change the user interface
and will leave the work to those that believe it is neccessary.

Until they do, it is not really meaningful to submit any of the other patches
because without working dataflash/run from SDRAM support, no recent AT91
board will work.

Still, I have submitted a patch and will not submit anything more
until I know if it is rejected or accepted.
I know from Peter that it is in the queue and understand that
since this is a new process for him, I will not put too much pressure.

> 
>> Removing support will cause more work for people
>> because the existing patches to make things work
>> will have to be modified...
>> 
>> What is the point of sabotaging others peoples efforts???
> 
> Instead of overwehemlimng everybody with a series of monster patches
> that change change U-Boot inside out you could try submitting small,
> isolated patches that fix the real problems step by step. If your
> patches are orthogonal, you could get at lest 90% of your stuff merged
> without any discussion, and then we could focus oin the remaining
> difficult parts.

I did submit a patch which basically split a file,
into two parts and moved them to different locations.
This rendered about 50 emails and requests for total rewrites...

> 
> Just because others don't agree with you does not mean  the  sabotage
> you. Robert Schwebel and others tried to explain this to you before.
> 

Disagreement with me is not sabotage, but I consider removing "board/at91rm9200dk"
just because it does not work, sabotage.
It forces additional work on me, and I fail to see any advantage.

> If you cannot advance with brute force, try using diplomacy  instead.
> Just insulting others is definitely not helpful.

At the moment I do not see how I can get patches accepted.
Hope to be surprised...

> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                ftp://at91dist:distrib at 81.80.104.162/

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <006201c79d56$86d17250$17031b0a@atmel.com> you wrote:
> 
> Things are broken, because Wolfgang refuses [some critical] patches
> fixing problems on

I don't refuse fixes, but we should not make things worse.

> AT91 on principle. - Dataflash should not be treated as random access
> memory.

We have an agreement here. Dataflash is a serial device,  no  memory,
and thus it should not be treated as random access memory.

> Still, I have submitted a patch and will not submit anything more
> until I know if it is rejected or accepted.

You will never know if something you don't submit would get  accepted
or not.

> Disagreement with me is not sabotage, but I consider removing
> "board/at91rm9200dk"
> just because it does not work, sabotage.

Nobody  ever  suggested  this.  Please  read  more  carefully  before
insulting people with causeless accusations.

> > If you cannot advance with brute force, try using diplomacy  instead.
> > Just insulting others is definitely not helpful.
> 
> At the moment I do not see how I can get patches accepted.
> Hope to be surprised...

I just tried to show you a way (once again).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It may be bad manners to talk with your mouth full, but it isn't  too
good either if you speak when your head is empty.

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Wed, May 23, 2007 at 05:44:53PM +0200, Ulf Samuelsson wrote:
> > In message <002601c79d29$4da6de70$3125b10a@atmel.com> you wrote:
> > Just because others don't agree with you does not mean  the  sabotage
> > you. Robert Schwebel and others tried to explain this to you before.
> > 
> 
> Disagreement with me is not sabotage, but I consider removing "board/at91rm9200dk"
> just because it does not work, sabotage.
> It forces additional work on me, and I fail to see any advantage.

I proposed removing board/at91rm9200dk just because noone was able to
review patch I sent. Here is reference:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/27997
Date: Tue, 24 Apr 2007 12:37:12 +0200
Subject: [PATCH] Fix U-Boot base address depending on CONFIG_SKIP_LOWLEVEL_INIT

I have strong feeling (based on zero interest I received), that noone is
interested in this board and therefore it is safe to remove support for
it. Got my point?

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Thu, May 24, 2007 at 11:14:13AM +0200, Ladislav Michl wrote:
> On Wed, May 23, 2007 at 05:44:53PM +0200, Ulf Samuelsson wrote:
> > Disagreement with me is not sabotage, but I consider removing "board/at91rm9200dk"
> > just because it does not work, sabotage.
> > It forces additional work on me, and I fail to see any advantage.
> 
> I proposed removing board/at91rm9200dk just because noone was able to
> review patch I sent. Here is reference:
> http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/27997
> Date: Tue, 24 Apr 2007 12:37:12 +0200
> Subject: [PATCH] Fix U-Boot base address depending on CONFIG_SKIP_LOWLEVEL_INIT
> 
> I have strong feeling (based on zero interest I received), that noone is
> interested in this board and therefore it is safe to remove support for
> it. Got my point?

Hmm, probably not... Ulf, please read that patch I sent link to and give
your ACK or NAK. I hope it will help to Peter (or Wolfgang) to decide if
they want to apply it.

Thanks,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> We also have board with NAND FLASH only and the number of those boards will 
> grow in the near future. The NAND command interface of course need a little 
> more typing, but I always configure a few environment variables to update the 
> images in the NAND FLASH. Something like:
> 
> => setenv nload 'tftp 200000 board/u-boot.bin'
> => setenv nupdate 'nand erase 0 40000;nand write 200000 0 40000'
> => setenv nupd 'run nload nupdate'

Yes, yes :-) Here I agree with Wolfgand and Stefan. U-Boot should
provide commands which reflect principle of device without any
abstraction. Knowing principle means usually less bad surprises coming
out from some hidden abstraction implementation details. That's good for
power users.

=> OK, then tell me how
   to compare a 6 MB
   file in flash with a 6MB
   file in SDRAM when
   your SDRAM is 8 MB.

   We are *not* running on
   PC's.

   There is nothing that stops
   "power users" from copying
   from dataflash to SDRAM 
   and then doing a compare.
   Power Users are limited
   by implementations which
   waste enormous resources.

   I would have more respects
   for exhibited views if writes
   to parallel flash is removed
   from cp.b...
   Parallel flash is clearly not
   "memory" for write 
    purposes, only for read
    purposes.
    Its existence in cp.b will 
    force endless #ifdefs
    or support for parallel flash
    will have to remain and
   bloat code.
 
    You could then argue that 
    support for parallel flash 
    should be removed from
    all commands to remove
    inconsistencies...

   I do not think this will
   happen because it is
   *useful* and because
   this affects boards which
   people that makes 
   decisions works with
   this. They do not work
   with dataflash and do
   not care about people
   that wants this.

   I think that consistency
   in argumentation is a
   reasonable demand.
   
  

   * BYTE WRITE

   Why should you waste
   time on copying dataflash
   to SDRAM when you can 
   do operations inside the
   internal SRAM.

   It is not desirable to transfer
   20,000 bits between CPU
   and dataflash when 100-200
   are sufficient.
   Personally I would like 
   everyone that did not 
   bother to read and under
   stand the AT45 dataflash 
   datasheets to do so before
   sending comments about  
   how the internal 
   implementation should look
   like.


Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <8r0FHjm57tdb.nQDcqRvm@mailout.dof.se> you wrote:
> 
> => OK, then tell me how
>    to compare a 6 MB
>    file in flash with a 6MB
>    file in SDRAM when
>    your SDRAM is 8 MB.

How are you doing it now? By doing it in chunks of a reasonable size.

>    It is not desirable to transfer
>    20,000 bits between CPU
>    and dataflash when 100-200
>    are sufficient.
>    Personally I would like 
>    everyone that did not 
>    bother to read and under
>    stand the AT45 dataflash 
>    datasheets to do so before
>    sending comments about  
>    how the internal 
>    implementation should look
>    like.

Note that we don't discuss inplementation yet. We just try to  define
an  API  that fits into the rest of U-Boot. Once we have an agreement
(or at least a decision), you are welcome to help  implementing  this
as efficiently as possible.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Veni, Vidi, VISA:
        I came, I saw, I did a little shopping.

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Sat, May 26, 2007 at 12:53:31PM +0200, Ulf Samuelsson wrote:
> => OK, then tell me how
>    to compare a 6 MB
>    file in flash with a 6MB
>    file in SDRAM when
>    your SDRAM is 8 MB.

Chunk by chunk?
But indeed, there is a little problem. It would be usefull to show
address which contains diferences from the beginning of dataflash
(or dataflash partition)...

>    We are *not* running on
>    PC's.

Perhaps it would help, if we could avoid ourselves to state the
obvious...

>    There is nothing that stops
>    "power users" from copying
>    from dataflash to SDRAM 
>    and then doing a compare.
>    Power Users are limited
>    by implementations which
>    waste enormous resources.

Anyone who copies whole file into RAM and then does compare has either a
lot of RAM or doesn't deserve to be called power user.

Lines 303-308 of common/cmd_mem.c reads (cmp command):
#ifdef CONFIG_HAS_DATAFLASH
        if (addr_dataflash(addr1) | addr_dataflash(addr2)){
                puts ("Comparison with DataFlash space not supported.\n\r");
                return 0;
        }
#endif

On my boards it leads to:
# cmp.l 10000000 C0000000 10
Comparison with DataFlash space not supported.

Therefore it seems I have to copy to RAM anyway and it doesn't seem to
be fixed by any patch at ftp 81.80.104.162.

>    I would have more respects
>    for exhibited views if writes
>    to parallel flash is removed
>    from cp.b...
>    Parallel flash is clearly not
>    "memory" for write 
>     purposes, only for read
>     purposes.
>     Its existence in cp.b will 
>     force endless #ifdefs
>     or support for parallel flash
>     will have to remain and
>    bloat code.

Erm... This interface is finished, contains finite number of features
and certainly finite numbers of #ifdefs. This number could be reduced
even more by removing hacks for MMC.

>     You could then argue that 
>     support for parallel flash 
>     should be removed from
>     all commands to remove
>     inconsistencies...
> 
>    I do not think this will
>    happen because it is
>    *useful* and because
>    this affects boards which
>    people that makes 
>    decisions works with
>    this. They do not work
>    with dataflash and do
>    not care about people
>    that wants this.

I have two AT91RM9200 based boards here. One boots from dataflash,
stores enviroment here and loads kernel from NAND. Sure I care about
dataflash support...

>    I think that consistency
>    in argumentation is a
>    reasonable demand.
>    
>    * BYTE WRITE
> 
>    Why should you waste
>    time on copying dataflash
>    to SDRAM when you can 
>    do operations inside the
>    internal SRAM.
> 
>    It is not desirable to transfer
>    20,000 bits between CPU
>    and dataflash when 100-200
>    are sufficient.

Could you please point exactly where I suggested such behaviour?

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> On Sat, May 26, 2007 at 12:53:31PM +0200, Ulf Samuelsson wrote:
>> => OK, then tell me how
>>    to compare a 6 MB
>>    file in flash with a 6MB
>>    file in SDRAM when
>>    your SDRAM is 8 MB.
> 
> Chunk by chunk?

Yes, but not by doing that manually.
It was suggested that you do not need any command
to do that compare since you can copy from dataflash to SDRAM.
If you use 64 kB buffers, then you have to type in 96 U.boot commands
to do that single compare.

> But indeed, there is a little problem. It would be usefull to show
> address which contains diferences from the beginning of dataflash
> (or dataflash partition)...
> 
>>    We are *not* running on
>>    PC's.
> 
> 
> Anyone who copies whole file into RAM and then does compare has either a
> lot of RAM or doesn't deserve to be called power user.
> 

The amount of flash and ram is typically determined by the need of 
the application, and not by the qualifications of the person running U-boot.

> Lines 303-308 of common/cmd_mem.c reads (cmp command):
> #ifdef CONFIG_HAS_DATAFLASH
>        if (addr_dataflash(addr1) | addr_dataflash(addr2)){
>                puts ("Comparison with DataFlash space not supported.\n\r");
>                return 0;
>        }
> #endif
> 
> On my boards it leads to:
> # cmp.l 10000000 C0000000 10
> Comparison with DataFlash space not supported.
> 
> Therefore it seems I have to copy to RAM anyway and it doesn't seem to
> be fixed by any patch at ftp 81.80.104.162.

That is funny because I have done that patch.

> 
>>    I would have more respects
>>    for exhibited views if writes
>>    to parallel flash is removed
>>    from cp.b...
>>    Parallel flash is clearly not
>>    "memory" for write 
>>     purposes, only for read
>>     purposes.
>>     Its existence in cp.b will 
>>     force endless #ifdefs
>>     or support for parallel flash
>>     will have to remain and
>>    bloat code.
> 
> Erm... This interface is finished, contains finite number of features
> and certainly finite numbers of #ifdefs. This number could be reduced
> even more by removing hacks for MMC.

It is not finished, since people would like to "clean" up the memory commands
but you are avoiding the point, in favour of advocacy.

Parallel flash CANNOT be written in the same way as SDRAM.
Why should then parallel flash be considered as memory.

I really do not advocate that this is changed, but I would like to see
some consistency in arguments.

> 
>>     You could then argue that 
>>     support for parallel flash 
>>     should be removed from
>>     all commands to remove
>>     inconsistencies...
>> 
>>    I do not think this will
>>    happen because it is
>>    *useful* and because
>>    this affects boards which
>>    people that makes 
>>    decisions works with
>>    this. They do not work
>>    with dataflash and do
>>    not care about people
>>    that wants this.
> 
> I have two AT91RM9200 based boards here. One boots from dataflash,
> stores enviroment here and loads kernel from NAND. Sure I care about
> dataflash support...
> 
>>    I think that consistency
>>    in argumentation is a
>>    reasonable demand.
>>    
>>    * BYTE WRITE
>> 
>>    Why should you waste
>>    time on copying dataflash
>>    to SDRAM when you can 
>>    do operations inside the
>>    internal SRAM.
>> 
>>    It is not desirable to transfer
>>    20,000 bits between CPU
>>    and dataflash when 100-200
>>    are sufficient.
> 
> Could you please point exactly where I suggested such behaviour?
> 

Wolfgang suggested byte writes should be implemented as 
1) Copy to SDRAM
2) Modify SDRAM
3) Write to Dataflash

which will result in above inefficiency.


> Best regards,
> ladis
>

Personally, I would like to see an architecture where every memory
registers itself in a common database.

When a memory command is executed, the command should be split 
the memory areas involved into pages, and execute the command
on each page.

Each driver would, if neccessary copy its data into a SDRAM buffer before use.

cp.b
     
     for each registred memory do
         if(src = parse(parameter 1)) != FAIL) 
                break;
         end if
     done
     if(src == FAIL) then
            src = SDRAM
    end if 

     for each registred memory do
         if(dst = parse(parameter 2)) != FAIL) 
                break;
         end if;
    done
     if(dst == FAIL) then
            dst = SDRAM
    end if

    /*
         Now you have src pointing to a descriptor for the first parameter
         and dst pointing to a descriptor for the second parameter.
        - Without any ifdefs, and easily extendible.
    */
    pageesize = determine_pagesize(src,dst);

    for(i = 0; i < size; i += pagesize) {
            Ensure that src is accessible using a memory pointer to SDRAM
                 * maybe by reading from storage to SDRAM
                 * if in SDRAM/par flash memory, just return pointer
            Copy page to destination, using access routine defined in storage driver.
    }


Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Mon, May 28, 2007 at 04:08:50PM +0200, Ulf Samuelsson wrote:
> > On Sat, May 26, 2007 at 12:53:31PM +0200, Ulf Samuelsson wrote:
> >> => OK, then tell me how
> >>    to compare a 6 MB
> >>    file in flash with a 6MB
> >>    file in SDRAM when
> >>    your SDRAM is 8 MB.
> > 
> > Chunk by chunk?
> 
> Yes, but not by doing that manually.
> It was suggested that you do not need any command
> to do that compare since you can copy from dataflash to SDRAM.
> If you use 64 kB buffers, then you have to type in 96 U.boot commands
> to do that single compare.

Not if you could run command in a loop.

> > But indeed, there is a little problem. It would be usefull to show
> > address which contains diferences from the beginning of dataflash
> > (or dataflash partition)...
> > 
> >>    We are *not* running on
> >>    PC's.
> >
> > Anyone who copies whole file into RAM and then does compare has either a
> > lot of RAM or doesn't deserve to be called power user.
> > 
> The amount of flash and ram is typically determined by the need of 
> the application, and not by the qualifications of the person running U-boot.

Sure. Point was that sane power user will compare chunk by chunk (6 MB
file and 8 MB RAM case).

> > Lines 303-308 of common/cmd_mem.c reads (cmp command):
> > #ifdef CONFIG_HAS_DATAFLASH
> >        if (addr_dataflash(addr1) | addr_dataflash(addr2)){
> >                puts ("Comparison with DataFlash space not supported.\n\r");
> >                return 0;
> >        }
> > #endif
> > 
> > On my boards it leads to:
> > # cmp.l 10000000 C0000000 10
> > Comparison with DataFlash space not supported.
> > 
> > Therefore it seems I have to copy to RAM anyway and it doesn't seem to
> > be fixed by any patch at ftp 81.80.104.162.
> 
> That is funny because I have done that patch.

Could you point me to it, please?

[snip]
> > Erm... This interface is finished, contains finite number of features
> > and certainly finite numbers of #ifdefs. This number could be reduced
> > even more by removing hacks for MMC.
> 
> It is not finished, since people would like to "clean" up the memory commands
> but you are avoiding the point, in favour of advocacy.

NOR interface is finished.

> Parallel flash CANNOT be written in the same way as SDRAM.
> Why should then parallel flash be considered as memory.

Mapped into address space, CAN be written in the same way as SDRAM.
Note that I'm not doing any advocacy here, I want acceptable solution
without drawbacks.

> I really do not advocate that this is changed, but I would like to see
> some consistency in arguments.

See below and try to imagine what would need to be done to support 64bit
virtual address space.

[snip]
> Wolfgang suggested byte writes should be implemented as 
> 1) Copy to SDRAM
> 2) Modify SDRAM
> 3) Write to Dataflash
> 
> which will result in above inefficiency.

That's only suggestion.

> Personally, I would like to see an architecture where every memory
> registers itself in a common database.

And memory is even IDE disc as you suggested in your database example?

> When a memory command is executed, the command should be split 
> the memory areas involved into pages, and execute the command
> on each page.

So here you basicaly proposing something like u-boot virtual memory.
What if I have storage greater than addresable area? NAND chips are
pretty close to that for example (and even today it is quite easy to
build such board using few more NAND chips) and consider design with
64MB of RAM, 2GB NAND and 1G SD card and 1G USB stick. Will you move
to 64bit address space? In bootloader? Bootloader has always been
something simple, usefull only to boot application which does the job.
Perhaps it would help if you could express what you expect from a
bootloader...

> Each driver would, if neccessary copy its data into a SDRAM buffer before use.
> 
> cp.b
>      
>      for each registred memory do
>          if(src = parse(parameter 1)) != FAIL) 
>                 break;
>          end if
>      done
>      if(src == FAIL) then
>             src = SDRAM
>     end if 
> 
>      for each registred memory do
>          if(dst = parse(parameter 2)) != FAIL) 
>                 break;
>          end if;
>     done
>      if(dst == FAIL) then
>             dst = SDRAM
>     end if
> 
>     /*
>          Now you have src pointing to a descriptor for the first parameter
>          and dst pointing to a descriptor for the second parameter.
>         - Without any ifdefs, and easily extendible.
>     */
>     pageesize = determine_pagesize(src,dst);
> 
>     for(i = 0; i < size; i += pagesize) {
>             Ensure that src is accessible using a memory pointer to SDRAM
>                  * maybe by reading from storage to SDRAM
>                  * if in SDRAM/par flash memory, just return pointer
>             Copy page to destination, using access routine defined in storage driver.
>     }

That's it... Above example needs 64bit virtual address space.

Principle described above has few serious drawbacks. Storage is no
longer storage, but randomly mapped memory. As a u-boot programer you
have to determine such memory map and as a u-boot user you have to
remember it. If you are using partitions you probably want to pass such
partitions mapping to linux. Curently it very easy and comfortale, you
can copy kernel and rootfs image to partion refered by name, without
even knowing where it is. And btw, where would you map OOB area of NAND
chip?

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Håvard Skinnemoen]

On 5/28/07, Ladislav Michl <ladis@linux-mips.org> wrote:
> Principle described above has few serious drawbacks. Storage is no
> longer storage, but randomly mapped memory. As a u-boot programer you
> have to determine such memory map and as a u-boot user you have to
> remember it.

Exactly. Giving storage devices which aren't memory mapped a "virtual"
address is a bad idea. And the database example is crap because it
depends on hardware paging, which isn't being proposed here (how many
architectures supported by u-boot can do 64-bit virtual address in
hardware?)

That said, I do think Ulf has a point -- being able to compare a block
of data in nand- or dataflash with something in memory (or other kinds
of storage) is a pretty neat feature. But it should not be done by
using "virtual" addresses (due to the problems described above), and
it should be implemented in a generic way. Pouring #ifdefs all over
cmd_mem.c is short-sighted and selfish.

I'm not sure if anyone's suggested this before, or whether it was
well-received or not, but why don't we generalize the cmd_mem syntax a
little? For example, let every memory address can be prefixed by an
optional "storage specifier" and a ':' character. The default "storage
specifier" is "mem", so that if it is omitted everything will work as
before, but you can also do things like

  cp.b df0:0x4200 0x85000000
  cmp.l 0x24000000 nand1.1:0x123456789

and so on. Whatever comes after ':' is passed to the storage handler
as a string, so if some storage types need 64-bit offsets, the handler
can support it without disturbing anything else.

What do you think about something like that? The actual syntax
probably needs some work to get right, and we need to take care to
ensure backwards compatibility of course.

This does actually come quite close to Ulf's proposal, but instead of
requiring the user to remember a "virtual address", we instead require
him to enter a logical device and an offset, ie.. kind of a simple VFS
without any actual files involved...

Haavard

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> On 5/28/07, Ladislav Michl <ladis@linux-mips.org> wrote:
>> Principle described above has few serious drawbacks. Storage is no
>> longer storage, but randomly mapped memory. As a u-boot programer you
>> have to determine such memory map and as a u-boot user you have to
>> remember it.
> 
> Exactly. Giving storage devices which aren't memory mapped a "virtual"
> address is a bad idea. And the database example is crap because it
> depends on hardware paging, which isn't being proposed here (how many
> architectures supported by u-boot can do 64-bit virtual address in
> hardware?)
> 
> That said, I do think Ulf has a point -- being able to compare a block
> of data in nand- or dataflash with something in memory (or other kinds
> of storage) is a pretty neat feature. But it should not be done by
> using "virtual" addresses (due to the problems described above), and
> it should be implemented in a generic way. Pouring #ifdefs all over
> cmd_mem.c is short-sighted and selfish.

My proposal removes all #ifdefs from memory commands.

> I'm not sure if anyone's suggested this before, or whether it was
> well-received or not, but why don't we generalize the cmd_mem syntax a
> little? For example, let every memory address can be prefixed by an
> optional "storage specifier" and a ':' character. The default "storage
> specifier" is "mem", so that if it is omitted everything will work as
> before, but you can also do things like
> 
>  cp.b df0:0x4200 0x85000000
>  cmp.l 0x24000000 nand1.1:0x123456789
> 

Which is 100% compatible with my proposal.

"cp.b df0:0x4200 0x85000000  ${size}"

is decoded by the command parser and the "cp" command is selected.

"cp" sends "df0:0x4200" down the chain of registred memory/storage devices.
The NAND flash driver will not understand "df0" so it ignores the parameter.
The dataflash driver detects that this is a dataflash and decides it is a success
and returns a pointer to a descriptor allowing the "cp" command to read/write dataflash.

Then "cp" sends down the "0x85000000" parameter, and it is decided
that this is located in SDRAM.

"cp" then calls the dataflash specific copy to sdram routine 
(from the descriptor) using 0x85000000 and ${size} as parameters.

The dataflash copy routine will (in the AT91 case) just set
up the initial address and copy chunks of 64 kB using the 
DMA controller (PDC).

No need for any #ifdefs to handle this as far as I see.

> and so on. Whatever comes after ':' is passed to the storage handler
> as a string, so if some storage types need 64-bit offsets, the handler
> can support it without disturbing anything else.
> 
> What do you think about something like that? The actual syntax
> probably needs some work to get right, and we need to take care to
> ensure backwards compatibility of course.
> 
> This does actually come quite close to Ulf's proposal, but instead of
> requiring the user to remember a "virtual address", we instead require
> him to enter a logical device and an offset, ie.. kind of a simple VFS
> without any actual files involved...

I never said that you need to supply an address, you need
to supply a parameter, but the syntax of this can be driver specific.

> 
> Haavard
> 


Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Mon, May 28, 2007 at 06:56:30PM +0200, Ulf Samuelsson wrote:
> > I'm not sure if anyone's suggested this before, or whether it was
> > well-received or not, but why don't we generalize the cmd_mem syntax a
> > little? For example, let every memory address can be prefixed by an
> > optional "storage specifier" and a ':' character. The default "storage
> > specifier" is "mem", so that if it is omitted everything will work as
> > before, but you can also do things like

As far as I remember it was proposed by Tolunay Orkun in 'Atmel Dataflash
hooks' thread:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/26126
There was no reaction.

> >  cp.b df0:0x4200 0x85000000
> >  cmp.l 0x24000000 nand1.1:0x123456789
> > 
> 
> Which is 100% compatible with my proposal.
> 
> "cp.b df0:0x4200 0x85000000  ${size}"

Okay, I'm sorry for not understanding you correctly. I have no objections
to this proposal (as I have no customers and can easily start using new
syntax :-))

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <20070528193940.GA3014@linux-mips.org> you wrote:
>
> > > I'm not sure if anyone's suggested this before, or whether it was
> > > well-received or not, but why don't we generalize the cmd_mem syntax a
> > > little? For example, let every memory address can be prefixed by an
> > > optional "storage specifier" and a ':' character. The default "storage
> > > specifier" is "mem", so that if it is omitted everything will work as
> > > before, but you can also do things like
> 
> As far as I remember it was proposed by Tolunay Orkun in 'Atmel Dataflash
> hooks' thread:
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/26126
> There was no reaction.

No explicit reaction, maybe.

But my position on this is clear: the "mem" commands are supposed  to
work  on  memory  (bus  addressable  memaory  that  is, as previously
defined a couple of times). No such prefixes will be accepted.

Instead,  support  for  storage  devices  shall  be  handled  by  the
respective  storage  device  commands, like "ide", "usb", "nand", and
(to be implemented) "dataflash" (or whatever name will be chosen).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Chapter 1 -- The story so  far:
In the beginning the Universe was created. This has  made  a  lot  of
people very angry and been widely regarded as a bad move.

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

This patch is obviously not going to be accepted in the main tree...

Here is my patch to allow
* cp.b from SDRAM to dataflash with CRC calculation and storage
* cp.b from dataflash to SDRAM with CRC calculation and check
* compare dataflash to SDRAM.
Looks like it disappeared from the 1.1.2-atmel version by mistake.

The reason for adding the CRC is that the CRC check used
when booting the kernel does not really trigger the user to think
along the right lines.
If you write the kernel after the root fs, you overwrite the beginning of the root fs
if the kernel does not fit.
If you write the kernel before you write the root fs, you will overwrite
the last part of the kernel if the kernel does not fit.

By doing the crc check when copying from the dataflash to SDRAM
you immediately pinpoint the problem.
If U-Boot contained a command to write the kernel to dataflash,
then this command could check that the image fits into the partition
allocated for the kernel, and would report a "kernel too large"
warning message.



diff -urN u-boot-1.1.4-0rig/common/cmd_mem.c u-boot-1.1.4/common/cmd_mem.c
--- u-boot-1.1.4-0rig/common/cmd_mem.c	2006-08-18 18:35:32.000000000 +0200
+++ u-boot-1.1.4/common/cmd_mem.c	2006-08-18 19:32:33.000000000 +0200
@@ -64,6 +64,7 @@
 }
 #endif

+
 #if (CONFIG_COMMANDS & CFG_CMD_MEMORY)

 #ifdef	CMD_MEM_DEBUG
@@ -71,6 +72,63 @@
 #else
 #define PRINTF(fmt,args...)
 #endif
+#ifdef CONFIG_HAS_DATAFLASH
+#define DF_PAGE_VALID	0x01
+typedef	unsigned char dfpagebuf[CFG_DATAFLASH_PAGE_SIZE];
+dfpagebuf		dfcache[3];		// Cache buffers for dataflash
+unsigned char	dfvalid[3];			// if DF_PAGE_VALID is set, then the, cache buffer contents are valid
+unsigned char	dflru[3];			// Least recently used algorithm to determine which buffer to reuse
+unsigned int		dfpage[3];		// TLB for cache, tells which page is loaded into dfcache
+
+void		flush_dfcache(void)
+{
+	dfvalid[0] = dfvalid[1] = dfvalid[2] = 0;
+	dflru[0] = 0;
+	dflru[1] = 1;
+	dflru[2] = 2;
+}
+
+ulong	translate(unsigned int addr)
+{
+	unsigned int	page = (addr) / CFG_DATAFLASH_PAGE_SIZE;	
+	unsigned int	index = (addr) - (page * CFG_DATAFLASH_PAGE_SIZE);
+	unsigned int	i,rc;
+	for(i = 0; i < 2; i++) {
+		if((page == dfpage[i]) && (dfvalid[i] & DF_PAGE_VALID)) {
+			if(dflru[0] == i) {
+				// nothing
+			} else if(dflru[1]  == i) {
+				// swap with 0
+				dflru[1] = dflru[0];
+				dflru[0] = i;
+			} else {
+				// shift down
+				dflru[2] = dflru[1];
+				dflru[1] = dflru[0];
+				dflru[0] = i;
+			}
+			return (unsigned int) &dfcache[i][index];
+		}
+	}
+	// not found
+	// use buffer found in dflru[2]
+	i = dflru[2];
+	if ((rc = read_dataflash(addr, CFG_DATAFLASH_PAGE_SIZE, dfcache[i])) == DATAFLASH_OK){
+		dflru[2] = dflru[1];
+		dflru[1] = dflru[0];
+		dflru[0] = i;
+		dfvalid[i] |= DF_PAGE_VALID;
+		return  (unsigned int) &dfcache[i][index];
+	}
+	return 0;	
+}
+void		df_writed(unsigned char *ldest, ulong  laddr)
+{
+
+}
+void		df_writew(unsigned char *ldest,ushort laddr) {}
+void		df_writeb(unsigned char *ldest, u_char laddr) {}
+#endif

 static int mod_mem(cmd_tbl_t *, int, int, int, char *[]);

@@ -316,6 +374,7 @@
 int do_mem_cmp (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
 	ulong	addr1, addr2, count, ngood;
+	ulong	laddr1, laddr2;
 	int	size;
 	int     rcode = 0;

@@ -338,12 +397,57 @@
 	count = simple_strtoul(argv[3], NULL, 16);

 #ifdef CONFIG_HAS_DATAFLASH
+/*
 	if (addr_dataflash(addr1) | addr_dataflash(addr2)){
 		puts ("Comparison with DataFlash space not supported.\n\r");
 		return 0;
 	}
+*/
+	if (addr_dataflash(addr1) | addr_dataflash(addr2)){
+		flush_dfcache();
+		ngood = 0;
+		while (count-- > 0) {
+			laddr1	= translate((unsigned int) addr1);
+			laddr2	= translate((unsigned int) addr2);
+			if (size == 4) {
+				ulong word1 = *(ulong *)laddr1;
+				ulong word2 = *(ulong *)laddr2;
+				if (word1 != word2) {
+					printf("word at 0x%08lx (0x%08lx) "
+						"!= word at 0x%08lx (0x%08lx)\n",
+						laddr1, word1, laddr2, word2);
+					rcode = 1;
+					break;
+				}
+			}
+			else if (size == 2) {
+				ushort hword1 = *(ushort *)laddr1;
+				ushort hword2 = *(ushort *)laddr2;
+				if (hword1 != hword2) {
+					printf("halfword at 0x%08lx (0x%04x) "
+						"!= halfword at 0x%08lx (0x%04x)\n",
+						laddr1, hword1, laddr2, hword2);
+					rcode = 1;
+					break;
+				}
+			}
+			else {
+				u_char byte1 = *(u_char *)laddr1;
+				u_char byte2 = *(u_char *)laddr2;
+				if (byte1 != byte2) {
+					printf("byte at 0x%08lx (0x%02x) "
+						"!= byte at 0x%08lx (0x%02x)\n",
+						laddr1, byte1, laddr2, byte2);
+					rcode = 1;
+					break;
+				}
+			}
+			ngood++;
+			addr1 += size;
+			addr2 += size;
+		}
+	} else {
 #endif
-
 	ngood = 0;

 	while (count-- > 0) {
@@ -384,6 +488,10 @@
 		addr1 += size;
 		addr2 += size;
 	}
+#ifdef CONFIG_HAS_DATAFLASH
+	}
+#endif
+

 	printf("Total of %ld %s%s were the same\n",
 		ngood, size == 4 ? "word" : size == 2 ? "halfword" : "byte",
@@ -484,11 +592,30 @@
 	/* Check if we are copying from RAM or Flash to DataFlash */
 	if (addr_dataflash(dest) && !addr_dataflash(addr)){
 		int rc;
+#ifdef	CONFIG_DATAFLASH_CRC
+		unsigned int crc;
+		unsigned char *p;		
+		puts ("Copy to DataFlash with CRC... ");
+		crc = crc32 (0, (const uchar *) addr, count*size);
+		// Save CRC in small endian format
+		printf("0x%08x written to [%08x] ... ",crc,(unsigned int) (dest + count * size));
+		p = (unsigned char *) addr+(count*size);
+		*p++ = (unsigned char) crc & 0xff;
+		crc >>= 8;
+
+		*p++ = (unsigned char) crc & 0xff;
+		crc >>= 8;

-		puts ("Copy to DataFlash... ");
+		*p++ = (unsigned char) crc & 0xff;
+		crc >>= 8;

-		rc = write_dataflash (dest, addr, count*size);
+		*p = (unsigned char) crc & 0xff;

+		rc = write_dataflash (dest, addr, count*size+4);
+#else
+		puts ("Copy to DataFlash... ");
+		rc = write_dataflash (dest, addr, count*size);
+#endif
 		if (rc != 1) {
 			dataflash_perror (rc);
 			return (1);
@@ -504,17 +631,70 @@
 #endif
 	){
 		int rc;
+#ifdef	CONFIG_DATAFLASH_CRC
+		unsigned char *p;
+		unsigned int crc,oldcrc;
+		puts ("Copy from DataFlash with CRC...");
+		rc = read_dataflash(addr, (count * size)+4, (char *) dest);
+		if (rc != 1) {
+			dataflash_perror (rc);
+			return (1);
+		}
+		// Read CRC in small endian format, MSB first
+		
+		p = (unsigned char *) dest + (count * size) + 3;
+		oldcrc = *p--;
+		oldcrc = (oldcrc << 8) | *p--;
+		oldcrc = (oldcrc << 8) | *p--;
+		oldcrc = (oldcrc << 8) | *p;
+		crc = crc32 (0, (const uchar *) dest, count*size);
+		if(crc != oldcrc) {
+			printf("\n\rBad CRC, %x expected, found %x... \n\r",oldcrc,crc);
+			return 1;
+		} else {
+				printf("[0x%x]",crc);
+		}
+#else
+		puts ("Copy from DataFlash...");
 		rc = read_dataflash(addr, count * size, (char *) dest);
 		if (rc != 1) {
 			dataflash_perror (rc);
 			return (1);
 		}
+#endif
+		if (rc != 1) {
+			dataflash_perror (rc);
+			return (1);
+		}
+		puts ("done\n\r");
 		return 0;
 	}

 	if (addr_dataflash(addr) && addr_dataflash(dest)){
-		puts ("Unsupported combination of source/destination.\n\r");
+		puts ("Cannot copy between two dataflash areas\n\r");
 		return 1;
+#if	0
+		unsigned int addr_page =  (unsigned int) addr / CFG_DATAFLASH_PAGE_SIZE ;
+		unsigned int dest_page =  (unsigned int) dest / CFG_DATAFLASH_PAGE_SIZE;
+		unsigned char *ldest,*laddr;		if(addr_page == dest_page)
+			puts ("Cannot copy within same page\n\r");
+			return 1;
+		}
+		flush_dfcache();
+		// Read into buffer 0
+		while (count-- > 0) {
+			laddr = translate(addr);	// Read source page if not inside
+			ldest = translate(dest);	// Read dest page if not inside
+			if (size == 4)
+				df_writed(ldest, *((ulong  *)laddr);
+			else if (size == 2)
+				df_writew(ldest,*((ushort *)laddr);
+			else
+				df_writeb(ldest, *((u_char *)laddr);
+			addr += size;
+			dest += size;
+		}
+#endif
 	}
 #endif



-- 
Best Regards,
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
links: www.avrfreaks.net; www.at91.com; avr32linux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070530/7eaf41d0/attachment.vcf 

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <465CA599.7070704@atmel.com> you wrote:
>
> This patch is obviously not going to be accepted in the main tree...

You are right.

The coding style violations alone (trailing white space, C++ comments,
broken indentation, incorrect brace style, ...) were reason enough to
reject it.

There are other, more serious reasons (like adding dataflash specific
type definitions and code to a global (and basicly  unrelated)  file,
and  of  course the whole concept of adding such code to the "memory"
commands where it does not belong. This has been discussed before.

For the record: I hereby reject this patch. Please implement this
function as part of a dataflash specific subcommand, following the
example of NAND flash. Also clean up the codingstyle before
resubmitting.


Some more comments below...

> Here is my patch to allow
> * cp.b from SDRAM to dataflash with CRC calculation and storage
> * cp.b from dataflash to SDRAM with CRC calculation and check
> * compare dataflash to SDRAM.
> Looks like it disappeared from the 1.1.2-atmel version by mistake.
> 
> The reason for adding the CRC is that the CRC check used
> when booting the kernel does not really trigger the user to think
> along the right lines.
> If you write the kernel after the root fs, you overwrite the beginning of the root fs
> if the kernel does not fit.
> If you write the kernel before you write the root fs, you will overwrite
> the last part of the kernel if the kernel does not fit.

If you want to do something like this (opinions about usefulnes  will
probably differ - I'm not going to discuss this here), you don't need
to  add  special  commands.  You  should  be able to use the existing
commands, eventually packed into a macro definition.

> By doing the crc check when copying from the dataflash to SDRAM
> you immediately pinpoint the problem.

I don't understand why your appended CRC word is in  any  way  better
than  our  embedded  / prepended one, the result of the check will be
the same in each case. If you need check the  CRC  independetly  from
the  boot  command,  you  can  always use the "imi" command, or "crc"
itself.

> If U-Boot contained a command to write the kernel to dataflash,
> then this command could check that the image fits into the partition
> allocated for the kernel, and would report a "kernel too large"
> warning message.

This is not an issue of a  special  write  command,  but  of  such  a
concept of partitions in flash memory which, at the moment, does not
exist.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is impractical for  the  standard  to  attempt  to  constrain  the
behavior  of code that does not obey the constraints of the standard.
                                                          - Doug Gwyn

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> 
> If you want to do something like this (opinions about usefulnes  will
> probably differ - I'm not going to discuss this here), you don't need
> to  add  special  commands.  You  should  be able to use the existing
> commands, eventually packed into a macro definition.
> 
* It is not a special command, it is a configurable side effect of
  reading/writing to dataflash.

* running mkimage on the host will of course generate the crc check
  but U-boot does not know that they thing you are copying to
  storage is an image so it will not check crc automatically.

  For your recommendation to work, people have to suspect that
  the things stored in flash is bad.
  In my experience, people do not realize that the image is bad, and
  think they have made a mistake when generating the kernel or the root fs
  and spend significant time trying to figure out what the problem
  is and then call me.
  If I generate/check the crc on all writes/reads, then this support
  problem will more or less go away.
  With your proposal, the support problem will remain.

  I can of course generate macros, but again, people will want to do
  their own macros, and they will run into the problem.

  Reducing support, is very important, and is worth the extra code space needed.


>> By doing the crc check when copying from the dataflash to SDRAM
>> you immediately pinpoint the problem.
> 
> I don't understand why your appended CRC word is in  any  way  better
> than  our  embedded  / prepended one, the result of the check will be
> the same in each case. If you need check the  CRC  independetly  from
> the  boot  command,  you  can  always use the "imi" command, or "crc"
> itself.
> 
>> If U-Boot contained a command to write the kernel to dataflash,
>> then this command could check that the image fits into the partition
>> allocated for the kernel, and would report a "kernel too large"
>> warning message.
> 
> This is not an issue of a  special  write  command,  but  of  such  a
> concept of partitions in flash memory which, at the moment, does not
> exist.
> 

The current dataflash drivers divides the flash into partitions.

In my private version, the partitions can have a name, and the address
of the partition is automatically stored in an environment variable
with this name,

It would be fairly easy to implement a command which flashes the kernel/rootfs,
to check that they fit into the named partition.

> 
> Best regards,
> 
> Wolfgang Denk
> 


-- 
Best Regards,
Ulf Samuelsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070530/f593bffc/attachment.vcf 

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

Dear Ulf,

in message <465CB41F.3050002@atmel.com> you wrote:
>
> * It is not a special command, it is a configurable side effect of
>   reading/writing to dataflash.

It is a special command, as "normal" copy operations don't do this.

> * running mkimage on the host will of course generate the crc check
>   but U-boot does not know that they thing you are copying to
>   storage is an image so it will not check crc automatically.

It will check it automatically whenever you use such  an  image,  for
example as part of a "bootm" or an "iminfo" command.

>   For your recommendation to work, people have to suspect that
>   the things stored in flash is bad.

If you get an error message that says "bad  CRC"  you  should  indeed
suspect that your image might have been corrupted.

>   In my experience, people do not realize that the image is bad, and
>   think they have made a mistake when generating the kernel or the root fs
>   and spend significant time trying to figure out what the problem
>   is and then call me.

Write a FAQ?

>   If I generate/check the crc on all writes/reads, then this support
>   problem will more or less go away.
>   With your proposal, the support problem will remain.

I cannot follow this argument. For me there is no difference  between
both CRC tests, except thatone is completely nonstandard and causes a
mess of code in areas where it does not belong.

> > This is not an issue of a  special  write  command,  but  of  such  a
> > concept of partitions in flash memory which, at the moment, does not
> > exist.
> 
> The current dataflash drivers divides the flash into partitions.
> 
> In my private version, the partitions can have a name, and the address
> of the partition is automatically stored in an environment variable
> with this name,

I guess that you probably invented your own implementation, or did you
extend the "mtdparts" command for this purpose?

> It would be fairly easy to implement a command which flashes the kernel/rootfs,
> to check that they fit into the named partition.

In the former case, please rewrite your code to fit into the existing
mtdparts framework. In the second case, please post your patches.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

Wolfgang Denk skrev:
> Dear Ulf,
> 
> in message <465CB41F.3050002@atmel.com> you wrote:
>> * It is not a special command, it is a configurable side effect of
>>   reading/writing to dataflash.
> 
> It is a special command, as "normal" copy operations don't do this.
> 
>> * running mkimage on the host will of course generate the crc check
>>   but U-boot does not know that they thing you are copying to
>>   storage is an image so it will not check crc automatically.
> 
> It will check it automatically whenever you use such  an  image,  for
> example as part of a "bootm" or an "iminfo" command.

And as I pointed out, this generates a problem.
The problem is less when the kernel is overwritten than
when the root fs is written.

> 
>>   For your recommendation to work, people have to suspect that
>>   the things stored in flash is bad.
> 
> If you get an error message that says "bad  CRC"  you  should  indeed
> suspect that your image might have been corrupted.
> 
>>   In my experience, people do not realize that the image is bad, and
>>   think they have made a mistake when generating the kernel or the root fs
>>   and spend significant time trying to figure out what the problem
>>   is and then call me.
> 
> Write a FAQ?

This assumes people find and read the FAQ, before they call me.
They don't...

>>   If I generate/check the crc on all writes/reads, then this support
>>   problem will more or less go away.
>>   With your proposal, the support problem will remain.
> 
> I cannot follow this argument. For me there is no difference  between
> both CRC tests, except thatone is completely nonstandard and causes a
> mess of code in areas where it does not belong.

The difference is how much knowledge you require from the user.
The average newbie does not know that you have added a CRC to the image
and is less aware that you can check the CRC using suggested commands.

This difference can be measured in the number of incoming telephones calls.

> 
>>> This is not an issue of a  special  write  command,  but  of  such  a
>>> concept of partitions in flash memory which, at the moment, does not
>>> exist.
>> The current dataflash drivers divides the flash into partitions.
>>
>> In my private version, the partitions can have a name, and the address
>> of the partition is automatically stored in an environment variable
>> with this name,
> 
> I guess that you probably invented your own implementation, or did you
> extend the "mtdparts" command for this purpose?

No, this is part of "drivers/dataflash.c" in the current trunk
This was added to u-boot 11 Jun 2003 according to CHANGELOG
The mtdparts command was added after 11 Jan 2005 according the CHANGELOG

The named partitions is a small extension of "drivers/dataflash.c"


> 
>> It would be fairly easy to implement a command which flashes the kernel/rootfs,
>> to check that they fit into the named partition.
> 
> In the former case, please rewrite your code to fit into the existing
> mtdparts framework. In the second case, please post your patches.


As you see above, I am extending existing code, which is not mtdparts
and since this extends the dataflash support you will reject it, so it is pointless
to even try to submit a patch for inclusion in main trunk.

The reason I sent the patch was to allow people to extend their own u-boot version.
I will make sure the patch is available in my own version as well.

The dataflash partitioning scheme is static, which is a disadvantage, but
If I fix anything, I probably make the partition sizes a configurable item
in my buildroot and generate the warning there, if the kernel size is non compliant.

Anyway mtdparts seems to depend on JFFS2.
That dependency needs to go away first.
If you want to store EXT2 fs in the rootfs partition, you should not have to add JFFS2 code.


> Best regards,
> 
> Wolfgang Denk
> 


-- 
Best Regards,
Ulf Samuelsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070530/76da2948/attachment.vcf 

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <465CC968.6090801@atmel.com> you wrote:
>
> > I guess that you probably invented your own implementation, or did you
> > extend the "mtdparts" command for this purpose?
> 
> No, this is part of "drivers/dataflash.c" in the current trunk
> This was added to u-boot 11 Jun 2003 according to CHANGELOG
> The mtdparts command was added after 11 Jan 2005 according the CHANGELOG
> 
> The named partitions is a small extension of "drivers/dataflash.c"

OK, so we have here another area in the staflash support that shall be
cleaned up and merged into one, common implementation. Please move
this into the "mtdparts" support.

> > In the former case, please rewrite your code to fit into the existing
> > mtdparts framework. In the second case, please post your patches.
> 
> As you see above, I am extending existing code, which is not mtdparts

From the maintenance point of view it is  better  to  avoid  multiple
different  and  incompatible  implementations of the same feature. As
your partition support cannot provide the fuctions that are addressed
by the "mtdparts" implementation, while "mtdparts" can replace yours,
both implementations should be merged into the "mtdparts" command.

> and since this extends the dataflash support you will reject it, so it is pointless
> to even try to submit a patch for inclusion in main trunk.

I do not reject dataflash support poer se. Please try  to  understand
that.  As  maintainer  of the whole project I just cannot accept that
each maintainer of  a  group  of  boards  comes  up  with  differeing
implementations  of  certain  functions  or  with  a diverging design
philosophy.

You know exactly what is wanted,  so  maybe  you  can  try  to  start
contributing  to  the  needed  new  parts instead of trying to extend
parts that have been declared to be candidates for replacement.  That
would be much more useful and less frustrating for everybody.

> The dataflash partitioning scheme is static, which is a disadvantage, but
> If I fix anything, I probably make the partition sizes a configurable item
> in my buildroot and generate the warning there, if the kernel size is non compliant.

If you fix anything, then please by making  it  compatible  with  the
poublic  U-Boot  source  tree,i. e. by using the mtdparts command for
this purpose.

> Anyway mtdparts seems to depend on JFFS2.
> That dependency needs to go away first.

Agreed. Patches are welcome.

> If you want to store EXT2 fs in the rootfs partition, you should not have to add JFFS2 code.

Agreed.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our way is peace.
	-- Septimus, the Son Worshiper, "Bread and Circuses",
	   stardate 4040.7.

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Wed, May 30, 2007 at 08:57:50AM +0200, Wolfgang Denk wrote:
> In message <465CC968.6090801@atmel.com> you wrote:
> > The dataflash partitioning scheme is static, which is a disadvantage, but
> > If I fix anything, I probably make the partition sizes a configurable item
> > in my buildroot and generate the warning there, if the kernel size is non compliant.
> 
> If you fix anything, then please by making  it  compatible  with  the
> poublic  U-Boot  source  tree,i. e. by using the mtdparts command for
> this purpose.

Here it might be usefull to avoid modifications of certain partition
sizes. For example partition containing environment shouldn't be
modified, because code which read it from U-Boot has size and offset
hardcoded, therefore modifying it will result to bad surprise...

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <20070530105256.GA7649@michl.2n.cz> you wrote:
>
> > If you fix anything, then please by making  it  compatible  with  the
> > poublic  U-Boot  source  tree,i. e. by using the mtdparts command for
> > this purpose.
> 
> Here it might be usefull to avoid modifications of certain partition
> sizes. For example partition containing environment shouldn't be
> modified, because code which read it from U-Boot has size and offset
> hardcoded, therefore modifying it will result to bad surprise...

The user might prepare for the  installation  of  a  new  version  of
U-Boot  where the environment is in new sectors (for example, because
U-Boot has grown after adding new features - been there  before),  or
for switching from single to redundant environment, or ...

So actually the user might want to do some clever thing. Please don;t
prevent him from doing that.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Abstainer: A weak person who yields to the temptation of denying him-
self a pleasure. A total abstainer is one who  abstains  from  every-
thing  but  abstention, and especially from inactivity in the affairs
of others.                                           - Ambrose Bierce

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

----- Original Message ----- 
From: "Wolfgang Denk" <wd@denx.de>
To: "Ladislav Michl" <ladis@linux-mips.org>
Cc: "Ulf Samuelsson" <ulf@atmel.com>; "uboot" <u-boot-users@lists.sourceforge.net>
Sent: Wednesday, May 30, 2007 3:43 PM
Subject: Re: [U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT


> In message <20070530105256.GA7649@michl.2n.cz> you wrote:
>>
>> > If you fix anything, then please by making  it  compatible  with  the
>> > poublic  U-Boot  source  tree,i. e. by using the mtdparts command for
>> > this purpose.
>> 
>> Here it might be usefull to avoid modifications of certain partition
>> sizes. For example partition containing environment shouldn't be
>> modified, because code which read it from U-Boot has size and offset
>> hardcoded, therefore modifying it will result to bad surprise...
> 
> The user might prepare for the  installation  of  a  new  version  of
> U-Boot  where the environment is in new sectors (for example, because
> U-Boot has grown after adding new features - been there  before),  or
> for switching from single to redundant environment, or ...
> 
> So actually the user might want to do some clever thing. Please don;t
> prevent him from doing that.
> 

Since everything I work on is dataflash based, U-Boot executes from SDRAM.
While certain partitions are write protected, you an easily unprotect any or all
of the dataflash pages.
From U-Boot you then can download the new U-Boot image to SDRAM using tftp
and then cp.b (at least for now :-) to dataflash and then reboot.

The new image has defined it own partitions, and the environment area
(defined by the new image) is initialized according to compile time values
of the new image

While the named partitions will initialize some environment variables, there
is nothing that forces the user to actually use these in the bootargs or anywhere else.
I want the novice user to have a straightforward path to boot Linux without hassle. 
This does not block anyone else from shooting themselves in the foot.



> Best regards,
> 
> Wolfgang Denk
> 
> -- 


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                ftp://at91dist:distrib at 81.80.104.162/

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

Best Regards
Ulf Samuelsson

Atmel Nordic AB
Visit: Kavalleriv?gen 24, 
       174 58 Sundbyberg
Mail: Box 2033
       174 52 Sundbyberg
SWEDEN
mail:ulf at atmel.com
Tel: +46 706 224457
________________ Sidrubrik f?r svar ________________ ?rende:	Re: [U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT F?rfattare: Ladislav Michl <ladis@linux-mips.org> Datum:		2007 maj 30:e 10:54 
On Wed, May 30, 2007 at 08:57:50AM +0200, Wolfgang Denk wrote:
> In message <465CC968.6090801@atmel.com> you wrote:
> > The dataflash partitioning scheme is static, which is a disadvantage, but
> > If I fix anything, I probably make the partition sizes a configurable item
> > in my buildroot and generate the warning there, if the kernel size is non compliant.
> 
> If you fix anything, then please by making  it  compatible  with  the
> poublic  U-Boot  source  tree,i. e. by using the mtdparts command for
> this purpose.

Here it might be usefull to avoid modifications of certain partition
sizes. For example partition containing environment shouldn't be
modified, because code which read it from U-Boot has size and offset
hardcoded, therefore modifying it will result to bad surprise...

=> We also need to understand if we are talking
about the same thing.
I have this feeling that
mtdparts exist to divide
the rootfs into several
areas while the dataflash
partioning is there purely
for U-boot purposes.

The partion use is:
1) AT91 bootstrap.
2) U-boot environment
3) U-boot image.
4) Kernel image
5) Root FS.

The sum of 1+2+3 is
always 256kB due to
df sector size.
The only programmable value
is the kernel size.

Nothing is ever written to
the dataflash to indicate
partion info and nothing
is passed to Linux 
except rootfs start adress in
bootargs.

The df partion is just for setttins protection
and (in my 1 year+ old patch)
sets a few environment
variables to contain the
start adress of kernel &
rootfs.



Can someone confirm that
mtdparts is the right way
to go?

Best Regards
Ulf Samuelsson


Best Regards
Ulf Samuelsson


Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ladislav Michl]

On Wed, May 30, 2007 at 01:34:19PM +0200, Ulf Samuelsson wrote:
> => We also need to understand if we are talking
> about the same thing.
> I have this feeling that
> mtdparts exist to divide
> the rootfs into several
> areas while the dataflash
> partioning is there purely
> for U-boot purposes.

Hmm, does it mean that you do not want to share dataflash partitioning
between U-Boot nad Linux?

> The partion use is:
> 1) AT91 bootstrap.
> 2) U-boot environment
> 3) U-boot image.
> 4) Kernel image
> 5) Root FS.
> 
> The sum of 1+2+3 is
> always 256kB due to
> df sector size.
> The only programmable value
> is the kernel size.

There are constrains I'd like to see implemented some generic way as
well...

> Nothing is ever written to
> the dataflash to indicate
> partion info and nothing
> is passed to Linux 
> except rootfs start adress in
> bootargs.

Partitioning is stored inside U-Boot environment. In case this is
written into dataflash, the above will not be true. Also Linux will
share this partition map, but can be told to not do so and also some
partitions can be read-only for Linux.

> The df partion is just for setttins protection
> and (in my 1 year+ old patch)
> sets a few environment
> variables to contain the
> start adress of kernel &
> rootfs.
>
> Can someone confirm that
> mtdparts is the right way
> to go?

It will definitely work for me the way I'm used to use it. I do not know
what is "the right way" in your mind, but I will try to answer your
questions as well as I can do.

(all my boards are using redundand environment which can be read and
written also from Linux - for firmware upgrading purposes)

Best regards,
	ladis

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <tRKYbCxtg4wg.vWbVtGHk@mailout.dof.se> you wrote:
>
> => We also need to understand if we are talking
> about the same thing.
> I have this feeling that
> mtdparts exist to divide
> the rootfs into several
> areas while the dataflash
> partioning is there purely
> for U-boot purposes.

Please see for example
http://www.denx.de/wiki/view/DULG/BootTimeConfigurationOfMTDPartitions,
and look up the section about "mtdparts" in
CHANGELOG-before-U-Boot-1.1.5

> Can someone confirm that
> mtdparts is the right way
> to go?

I hereby confirm that it is the right way to go, as  it  is  the  way
that  is  supported in the public U-Boot tree, and that shall be used
to provide partition information for MTD devices in Linux.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I've got to get something inside me. Some coffee  or  something.  And
then the world will somehow be better.
                                     - Terry Pratchett, _Men at Arms_

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> In message <tRKYbCxtg4wg.vWbVtGHk@mailout.dof.se> you wrote:
>>
>> => We also need to understand if we are talking
>> about the same thing.
>> I have this feeling that
>> mtdparts exist to divide
>> the rootfs into several
>> areas while the dataflash
>> partioning is there purely
>> for U-boot purposes.
> 
> Please see for example
> http://www.denx.de/wiki/view/DULG/BootTimeConfigurationOfMTDPartitions,
> and look up the section about "mtdparts" in
> CHANGELOG-before-U-Boot-1.1.5
> 

OK, seems reasonable to use mtdparts, except that I think
it would be useful to be able to supply arguments in an incremental way
so you can build up your partition table using multiple mtdparts commands.

Also, I am not sure that mtdparts know about 1056 byte pages.
Maybe "k" could mean 1056 for dataflash parts?

Best Regards
Ulf Samuelsson

[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <019201c7a2ef$47e4aa00$0302a8c0@atmel.com> you wrote:
>
> Also, I am not sure that mtdparts know about 1056 byte pages.
> Maybe "k" could mean 1056 for dataflash parts?

mtdparts is supposed to be 100% compatible with the  MTD  commandline
processing  in  Linux. How is commandline configuration for dataflash
implemented there?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The game of life is a game of boomerangs.  Our  thoughts,  deeds  and
words return to us sooner or later with astounding accuracy.