[U-Boot-Users] Running w/o flash

[U-Boot-Users] Running w/o flash

[Matt Gessner]

Hi,

Can someone please point me to documentation that describes how to
configure u-boot to not use traditional flash but still allow things
like NAND and Dataflash?

My board doesn't have traditional flash so I'm not sure why I need to
tell u-boot that there is some.

I suppose it may be the case that I have to pretend it's there but never
use it, but I would like confirmation of this if possible.

Thanks,

Regards,

Matt Gessner

[U-Boot-Users] Running w/o flash

[Matt Gessner]

When I do that, cramfs fails to build.

I'm using JFFS2, if that helps.

Regards,

Matt

> -----Original Message-----
> From: Ulf Samuelsson [mailto:ulf at atmel.com]
> Sent: Tuesday, March 27, 2007 12:07 PM
> To: Matt Gessner
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Running w/o flash
> 
> Matt Gessner skrev:
> > Hi,
> >
> > Can someone please point me to documentation that describes how to
> > configure u-boot to not use traditional flash but still allow things
> > like NAND and Dataflash?
> >
> > My board doesn't have traditional flash so I'm not sure why I need
to
> > tell u-boot that there is some.
> >
> > I suppose it may be the case that I have to pretend it's there but
never
> > use it, but I would like confirmation of this if possible.
> >
> > Thanks,
> 
> You set CFG_NO_FLASH in your <board.h>
> The current U-Boot lacks patches, so you still get some bloat...
> 
> Atmels U-Boot has more patches.
> Have extracted them and I plan to send it to the list shortly.
> 
> --
> Best Regards,
> Ulf Samuelsson

[U-Boot-Users] Running w/o flash

[Ulf Samuelsson]

Matt Gessner skrev:
> Hi,
> 
> Can someone please point me to documentation that describes how to
> configure u-boot to not use traditional flash but still allow things
> like NAND and Dataflash?
> 
> My board doesn't have traditional flash so I'm not sure why I need to
> tell u-boot that there is some.
> 
> I suppose it may be the case that I have to pretend it's there but never
> use it, but I would like confirmation of this if possible.
> 
> Thanks,

You set CFG_NO_FLASH in your <board.h>
The current U-Boot lacks patches, so you still get some bloat...

Atmels U-Boot has more patches.
Have extracted them and I plan to send it to the list shortly.

-- 
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/20070327/e6ee8e58/attachment.vcf 

[U-Boot-Users] Running w/o flash

[Wolfgang Denk]

In message <4609412E.8010500@atmel.com> you wrote:
> 
> You set CFG_NO_FLASH in your <board.h>
> The current U-Boot lacks patches, so you still get some bloat...

I'm not sure what you are referring to. There are boards without  any
flash  in  the  source  tree  that are supposed to build and run just
fine...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.

[U-Boot-Users] Running w/o flash

[Dave Ellis]

Matt Gessner wrote:

> Subject: Re: [U-Boot-Users] Running w/o flash
> 
> When I do that [set CFG_NO_FLASH], cramfs fails to build.
> 
> I'm using JFFS2, if that helps.

Here's a patch I developed to allow JFFS2 to work with
CFG_NO_FLASH (which really seems to mean CFG_NO_NOR_FLASH).
It works as part of a board port I'm working on, but I haven't
even tried building the official tree with it after 
cherrypicking it.

It works with this configuration:

#define CONFIG_COMMANDS							\
		       ((CONFIG_CMD_DFL	|	/* start with default	*/ \
			CFG_CMD_PING |		/* ping is handy	*/ \
			CFG_CMD_USB |		/* we have USB on some	*/ \
			CFG_CMD_NAND |		/* NAND support		*/ \
			CFG_CMD_MII |		/* MII for PHY setup	*/ \
			CFG_CMD_JFFS2 ) &	/* JFFS2 for boot	*/ \
		      ~(CFG_CMD_FLASH |		/* have no NOR flash	*/ \
			CFG_CMD_IMLS |		/* needs NOR flash	*/ \
			CFG_CMD_FPGA ))		/* have no FPGA		*/
/* this must be included AFTER the definition of CONFIG_COMMANDS (if any) */
#include <cmd_confdefs.h>

#define CONFIG_JFFS2_CMDLINE
#define CONFIG_JFFS2_NAND	1	/* jffs2 on nand support */
#define CFG_NO_FLASH		/* no NOR flash */
#define CONFIG_HAS_DATAFLASH	/* has Atmel data flash */

Dave

--
Dave Ellis
___________________________________________________
SIXNET?- Truly Open Industrial Automation Solutions 
PO Box 767, 331 Ushers Road, Clifton Park, NY?12065 
Phone: +1(518)877-5173, ?Facsimile: +1(518)877-8346 
E-mail: mailto:dge at sixnetio.com
Get product details at http://www.sixnetio.com  

[U-Boot-Users] Running w/o flash

[Wolfgang Denk]

In message <C8F551D39A7C724E987CF8DD11D317837389C4@svr3.sixnetio.com> you wrote:
>
> Here's a patch I developed to allow JFFS2 to work with
> CFG_NO_FLASH (which really seems to mean CFG_NO_NOR_FLASH).

CFG_NO_FLASH means no flash memory at all. It is mutually exclusive
with CFG_CMD_FLASH, although this is not checked anywhere.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Schshschshchsch.
	-- The Gorn, "Arena", stardate 3046.2

[U-Boot-Users] Running w/o flash

[Dave Ellis]

Wolfgank Denk wrote: 

> > Here's a patch I developed to allow JFFS2 to work with
> > CFG_NO_FLASH (which really seems to mean CFG_NO_NOR_FLASH).
> 
> CFG_NO_FLASH means no flash memory at all. It is mutually exclusive
> with CFG_CMD_FLASH, although this is not checked anywhere.

Wolfgang,
 
I agree that's what it should mean, but then it would also be
mutually exclusive with CFG_CMD_NAND and CONFIG_HAS_DATAFLASH, and
that's not how it is actually used. All the uses I see are to
avoid using things that require CFG_CMD_FLASH.

I'd like to eliminate CFG_NO_FLASH and replace it with 
!(CONFIG_COMMANDS & CFG_CMD_FLASH). Would you accept that?
The only problem configurations are the MPC8xxx configurations.
Many of them are based on MPC8540ADS.h and MPC8560ADS.h, which
define CFG_NO_FLASH when CFG_RAMBOOT is defined, but don't
disable CFG_CMD_FLASH. I would make those like MPC8641HPCN.h,
which does disable CFG_CMD_FLASH.

If you (and the mpc8xxx custodians) agree with this approach
I'll prepare a patch.

Thanks,

Dave

--
Dave Ellis
___________________________________________________
SIXNET?- Truly Open Industrial Automation Solutions 
PO Box 767, 331 Ushers Road, Clifton Park, NY?12065 
Phone: +1(518)877-5173, ?Facsimile: +1(518)877-8346 
E-mail: mailto:dge at sixnetio.com
Get product details at http://www.sixnetio.com  

[U-Boot-Users] Running w/o flash

[Wolfgang Denk]

Dear Dave,

in message <C8F551D39A7C724E987CF8DD11D31783A76767@svr3.sixnetio.com> you wrote:
>
> > CFG_NO_FLASH means no flash memory at all. It is mutually exclusive
> > with CFG_CMD_FLASH, although this is not checked anywhere.
>  
> I agree that's what it should mean, but then it would also be
> mutually exclusive with CFG_CMD_NAND and CONFIG_HAS_DATAFLASH, and

No, not really. Because NAND and DataFlash are not flash MEMORY, they
are STORAGE devices based on some flash technology.

You may find I'm nitpicking here, but please read the lengthy  thread
"Running  w/o  flash" where I've been discussing exactly this problem
with Ulf Samuelsson again and again.

[It's quite some coincidence that your patch is posted just now.]

> that's not how it is actually used. All the uses I see are to
> avoid using things that require CFG_CMD_FLASH.

This makes sense to me.

> I'd like to eliminate CFG_NO_FLASH and replace it with 
> !(CONFIG_COMMANDS & CFG_CMD_FLASH). Would you accept that?

I think I would if you change only this, i. e. leave the basic  logic
in "common/cmd_flash.c" as is. But I guess Ulf would jump in squares.

> The only problem configurations are the MPC8xxx configurations.
> Many of them are based on MPC8540ADS.h and MPC8560ADS.h, which
> define CFG_NO_FLASH when CFG_RAMBOOT is defined, but don't
> disable CFG_CMD_FLASH. I would make those like MPC8641HPCN.h,
> which does disable CFG_CMD_FLASH.

This is definitely not a good idea. One pretty common usage patttern
is to load anU-Boot image to RAM and use this to load and program the
"real" image to flash, so flash command support should be kept.

For me the question is why the boards define CFG_NO_FLASH  then.  You
will have to check this with the board maintainers and the custodian.

> If you (and the mpc8xxx custodians) agree with this approach
> I'll prepare a patch.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is easier to write an incorrect program than understand a  correct
one.

[U-Boot-Users] Running w/o flash

[Andy Fleming]

On 3/28/07, Wolfgang Denk <wd@denx.de> wrote:
> Dear Dave,
>
> in message <C8F551D39A7C724E987CF8DD11D31783A76767@svr3.sixnetio.com> you wrote:

> > The only problem configurations are the MPC8xxx configurations.
> > Many of them are based on MPC8540ADS.h and MPC8560ADS.h, which
> > define CFG_NO_FLASH when CFG_RAMBOOT is defined, but don't
> > disable CFG_CMD_FLASH. I would make those like MPC8641HPCN.h,
> > which does disable CFG_CMD_FLASH.
>
> This is definitely not a good idea. One pretty common usage patttern
> is to load anU-Boot image to RAM and use this to load and program the
> "real" image to flash, so flash command support should be kept.
>
> For me the question is why the boards define CFG_NO_FLASH  then.  You
> will have to check this with the board maintainers and the custodian.

Sadly, we no longer remember why it was set.  I wouldn't object to
someone removing the CFG_NO_FLASH definition if they could test it.

I might not even object that much if it broke RAM_BOOT.  Get a BDI and
program the flash, people!  ;)

I would even agree to test that change on one of our boards if you
remind me what I need to change to boot from RAM.  I've not booted
from RAM since we were bringing up the 8540!

Andy

[U-Boot-Users] Running w/o flash

[Dave Ellis]

Andy Fleming wrote: 
> On 3/28/07, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Dave,

> > > The only problem configurations are the MPC8xxx configurations.
> > > Many of them are based on MPC8540ADS.h and MPC8560ADS.h, which
> > > define CFG_NO_FLASH when CFG_RAMBOOT is defined, but don't
> > > disable CFG_CMD_FLASH. I would make those like MPC8641HPCN.h,
> > > which does disable CFG_CMD_FLASH.
> >
> > This is definitely not a good idea. One pretty common usage patttern
> > is to load anU-Boot image to RAM and use this to load and program the
> > "real" image to flash, so flash command support should be kept.
> >
> > For me the question is why the boards define CFG_NO_FLASH then.  You
> > will have to check this with the board maintainers and the custodian.
> 
> Sadly, we no longer remember why it was set.  I wouldn't object to
> someone removing the CFG_NO_FLASH definition if they could test it.
> 
> I might not even object that much if it broke RAM_BOOT.  Get a BDI and
> program the flash, people!  ;)
> 
> I would even agree to test that change on one of our boards if you
> remind me what I need to change to boot from RAM.  I've not booted
> from RAM since we were bringing up the 8540!

I don't have the hardware to test it, but apparently you build for 
RAM_BOOT by setting TEXT_BASE below the start of flash. I tried 
building MPC8540ADS with 'make TEXT_BASE=0xf0080000' (I don't know 
if that is the right address but at least it is in SDRAM) and it 
won't build because CFG_NO_FLASH and CFG_CMD_FLASH are incompatible.

If I remove CFG_NO_FLASH it almost builds but I get a relocation error
in cpu/mpc85xx/start.o (maybe 0xf0080000 isn't the best address?)
Also, the comment on CFG_NO_FLASH is 'Flash is not usable now', so I
don't liking removing it.

If I disable CFG_CMD_FLASH and CFG_CMD_IMLS like MPC8641HPCN does
for RAM_BOOT it builds clean. Jon, did you actually run the RAM_BOOT
configuration for the MPC8641HPCN? This is at least less broken
than it is now, so I'd like to take this approach, but I can't
test more than the build.

Dave

--
Dave Ellis
___________________________________________________
SIXNET?- Truly Open Industrial Automation Solutions 
PO Box 767, 331 Ushers Road, Clifton Park, NY?12065 
Phone: +1(518)877-5173, ?Facsimile: +1(518)877-8346 
E-mail: mailto:dge at sixnetio.com
Get product details at http://www.sixnetio.com  

[U-Boot-Users] BDI2000 with ML403 board.

[Leonid]

Hi:

Did anybody use BDI2000 with ML403 Xilinx board?

Does anybody have ML403 configuration file another than that on ultsol
site (attached)? And what about registers' definition file for ppc405?

With .cfg file I took from ultsol site I cannot step through code and
get break points (I'm running u-boot now). It also complains upon reboot
though eventually succeeds:

CONFIG: loading configuration file passed
- TARGET: processing user reset request
- TARGET: resetting target passed
- TARGET: processing target startup ....
- TARGET: core #0 PVR is 0x20011470
*** INIT: #0 WSPR 954 0x00000000 failed
# PPC: JTAG instruction stuff overrun
*** TARGET: processing target startup failed
# PPC: JTAG instruction stuff overrun
- TARGET: target will be restarted in 10 sec
- TARGET: processing user reset request
- TARGET: resetting target passed
- TARGET: processing target startup ....
*** TARGET: core #0 startup failed
# PPC: JTAG instruction stuff overrun
*** TARGET: processing target startup failed
# PPC: JTAG instruction stuff overrun
- TARGET: target will be restarted in 10 sec
- TARGET: processing user reset request
- TARGET: resetting target passed
- TARGET: processing target startup ....
- TARGET: core #0 PVR is 0x20011470
- TARGET: processing target startup passed

u-boot is running (first stage boot loader loads it from flash) yet I
cannot neither stop the target, nor get breakpoints.

Thanks,

Leonid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ml403_bdi.cfg
Type: application/octet-stream
Size: 5678 bytes
Desc: ml403_bdi.cfg
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070329/02580396/attachment.obj 

[U-Boot-Users] BDI2000 with ML403 board.

[Wolfgang Denk]

In message <406A31B117F2734987636D6CCC93EE3C0133FCE7@ehost011-3.exch011.intermedia.net> you wrote:
> 
> Does anybody have ML403 configuration file another than that on ultsol
> site (attached)? And what about registers' definition file for ppc405?

What's wrong with that file?

The register definitions file is on the floppy disk with the BDI2000
firmware...

> With .cfg file I took from ultsol site I cannot step through code and
> get break points (I'm running u-boot now). It also complains upon reboot
> though eventually succeeds:
> 
> CONFIG: loading configuration file passed
> - TARGET: processing user reset request
> - TARGET: resetting target passed
> - TARGET: processing target startup ....
> - TARGET: core #0 PVR is 0x20011470
> *** INIT: #0 WSPR 954 0x00000000 failed
> # PPC: JTAG instruction stuff overrun

You seem to have JTAG communication problems...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I know engineers. They love to change things.             - Dr. McCoy

[U-Boot-Users] BDI2000 with ML403 board.

[Leonid]

On Thursday, March 29, 2007 4:10 PM Wolfgang Denk wrote:
> The register definitions file is on the floppy disk with the BDI2000
> firmware...

Yes, I've found it.

> > With .cfg file I took from ultsol site I cannot step through code
and
> > get break points (I'm running u-boot now). It also complains upon
reboot
> > though eventually succeeds:
> > 
> > CONFIG: loading configuration file passed
> > - TARGET: processing user reset request
> > - TARGET: resetting target passed
> > - TARGET: processing target startup ....
> > - TARGET: core #0 PVR is 0x20011470
> > *** INIT: #0 WSPR 954 0x00000000 failed
> > # PPC: JTAG instruction stuff overrun

> You seem to have JTAG communication problems...

No doubt. The trick is to find correct combination of EDK project, BDI
config file and u-boot/kernel projects to make entire thing work. And
also cable we've prepared could be bad...

Best regards,

Leonid.

[U-Boot-Users] Running w/o flash

[Wolfgang Denk]

Dear Ulf,

in message <003d01c770fe$fc7b1f80$01c4af0a@Glamdring> you wrote:
>
> Their problem with you is that you ignore patch request.

Please be fair - I did not ignore pathches, I did not find time to
process them. The end effect may be the same, but there is still a big
difference.

> Not even acknowledgement for 9 months and this was
> 6 months ago.

What should I ack? That I received the patch? I am subscribed to  the
mailing  list.  I  receive  all  postings, and I can find them in the
archives. Just sending a "received" message seems useless to me.

> This is a systematic problem, which you are trying to fixed by
> introducing guardian.

Indeed. Please believe me, the previous situation was as  frustrating
to me as it was to you and others.

> I see is a as pointless in even trying, unless you are
> prepared to accept at least existing code to be merged

I did not object against this. Lets see what others and especially the
custodian say.

> Once you have accepted blame, you do not assume responsibility 
> for it, you want to offload all the work to others.
> You have no sensibility for other peoples priorities.

I spend an considerable amount of time in the past few days trying to
overcome the conflict you have with me. This was important to me,  as
I  think  that most of your contributions are valuable for the U-Boot
community, even though I disagree with  a  few  directions  you  have
taken.  All  my  attempts  seem to have failed. Instead of helping to
de-escalate the situation, you continue to insult me.

I stop here. I tried, and failed, again.


> If you want to change U-boot, then do so, but only when 
> you have a definition of how you want to change that.

The definition has been made. See the archives.

> Meanwhile there are AT91 customers which spends a lot of time
> trying to overcome the problems you are causing by 
> a position, which could be significantly different if you
> could see it from my (and not unlikely Atmels position)

I can see it from your position.  But  as  maintainer  of  the  whole
project,  I  cannot  allow  for each and every special solution. I've
done this too often before, and the result  has  always  caused  more
harm  that benefit. I cannot accept each and every contribution, even
if it solves a local problem or helps a certain  group  of  users.  I
have to reject stuff that breaks consistency and design principles of
the U-Boot code, at least when a better way to solve this problem is
known and feasible.

I am aware that we cannot replace Dataflash  support  with  something
new  and  better  immediately, so you can be assured that it won't be
ripped out. But I will also reject patches even extend  this  current
implementation.  If  you  want  to help, please do this by helping to
replace that old code instead of adding to it.

If you really have the AT91 customers in mind, your best contribution
is to participate in the new design and implementation, so your ideas
and wishes can be considered.


Let's stop this discussion now,  please.  I  don;t  see  any  results
coming out of it.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"If you can, help others. If you can't, at least don't hurt  others."
- the Dalai Lama

[U-Boot-Users] Running w/o flash

[Ulf Samuelsson]

> Dear Ulf,
> 
> in message <022201c770c3$43d20740$01c4af0a@Glamdring> you wrote:
>> 
>> Sorry, but I do not work in the Atmel AT91 Product Line
>> and I believe that they are the ones that should develop this.
>> 
>> However, They have already given up on you and are looking for an 
>> alternative solution.
> 
> I'm sorry to hear that. Is there anybody I could contact  to  try  to
> sort out their problems with me?
> 
> 

Their problem with you is that you ignore patch request.
Not even acknowledgement for 9 months and this was
6 months ago.

This is a systematic problem, which you are trying to fixed by
introducing guardian.

When I now try to resubmit 15 months old code (or older)
you want this to be totally rewritten in a way which is undefined..

I see is a as pointless in even trying, unless you are
prepared to accept at least existing code to be merged

>> >From my point of view, the best approach is that Grant Applies
>> my patches on his local tree and fixes the mess he has put us in.
> 
> Stop, please be fair. Grant is not to blame here.
> 
> The culprit is me. When the Dataflash  code  was  added,  I  did  not
> really  know  what DataFlash is, and I did not take the time to study
> the code thoroughly enough to understand all the implications. It was
> my fault that this code was ever added to the U-Boot tree. If  I  had
> raised my concerns earlier, all of this would have been much easier.
> 

Once you have accepted blame, you do not assume responsibility 
for it, you want to offload all the work to others.
You have no sensibility for other peoples priorities.

If you want to change U-boot, then do so, but only when 
you have a definition of how you want to change that.
Meanwhile there are AT91 customers which spends a lot of time
trying to overcome the problems you are causing by 
a position, which could be significantly different if you
could see it from my (and not unlikely Atmels position)

> But I did not understand this then, and now we have the mess. But this
> mess is my fault, not Grant's.
> 
> Grant is trying to help cleaning up.
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
> Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Quote from the Boss... "I didn't say it was your fault.  I said I was
> going to blame it on you."
>

[U-Boot-Users] Running w/o flash

[Wolfgang Denk]

Dear Ulf,

in message <022201c770c3$43d20740$01c4af0a@Glamdring> you wrote:
> 
> Sorry, but I do not work in the Atmel AT91 Product Line
> and I believe that they are the ones that should develop this.
> 
> However, They have already given up on you and are looking for an 
> alternative solution.

I'm sorry to hear that. Is there anybody I could contact  to  try  to
sort out their problems with me?


> >From my point of view, the best approach is that Grant Applies
> my patches on his local tree and fixes the mess he has put us in.

Stop, please be fair. Grant is not to blame here.

The culprit is me. When the Dataflash  code  was  added,  I  did  not
really  know  what DataFlash is, and I did not take the time to study
the code thoroughly enough to understand all the implications. It was
my fault that this code was ever added to the U-Boot tree. If  I  had
raised my concerns earlier, all of this would have been much easier.

But I did not understand this then, and now we have the mess. But this
mess is my fault, not Grant's.

Grant is trying to help cleaning up.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Quote from the Boss... "I didn't say it was your fault.  I said I was
going to blame it on you."

[U-Boot-Users] Running w/o flash

[Ulf Samuelsson]

>> Exactly, but there is flash, but not any *parallel* flash
>> so the flash commands are needed, but not the stuff
>> related to parallel flash.
>
> Instead of trying to extend the current, deprecated implementation, I
> would like to ask you to rather help to eliminate and replace it with
> something better.
>

Sorry, but I do not work in the Atmel AT91 Product Line
and I believe that they are the ones that should develop this.

However, They have already given up on you and are looking for an 
alternative solution.

What I am trying to do is to ensure that the existing work
is made available to our customers.

Since Grant want to change it, then he should do so, and promptly
since now his "idea" seems to block everything.

From my point of view, the best approach is that Grant Applies
my patches on his local tree and fixes the mess he has put us in.

> Thanks.
>
> 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:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR
link: www.avrfreaks.net 

[U-Boot-Users] Running w/o flash

[Wolfgang Denk]

In message <46095C4B.2090505@atmel.com> you wrote:
>
> > No. The whole file is not compiled as it starts
> > 
> > 	#if (CONFIG_COMMANDS & CFG_CMD_FLASH)
> > 
> > If you have no flash, you need no flash commands, so you don't define
> > CFG_CMD_FLASH and everything is fine.
> 
> I have flash, just not parallel flash.
> and I need the flash commands but not the stuff related to parallel flash.

There is no such concept as "parallel"  flash  in  U-Boot.  The  term
"flash"  is usually (*) used to name flash memory, i. e. some form of
non-volatile,  byte-addressable,  often  block-erasable  memory.  And
before  there is more confusion in terms: memory is something the CPU
can address on the address bus and read/write  data  from/to  on  the
data bus.

(*) The "usually" above refers to the fact that there are other types
    of storage devices like NAND flash, data flash, CompactFlash, ...
    that also use  the  work  "flash"  in  their  name,  but  without
    providing  a memory-like interface, so it is technically wrong to
    call these "flash memory".

The U-Boot command set enabled by the CFG_CMD_FLASH option provides
support for flash memory. Similar, the command set CFG_CMD_MEMORY
provides additional commands to operate on flash and other memory
types.

In U-Boot, the meaning of the term "flash" is consistent, i. e.  both
CFG_NO_FLASH and CFG_CMD_FLASH refer to exactly the same definition:
flash memory.

If you define CFG_NO_FLASH it makes no sense to define  CFG_CMD_FLASH
as  "no  flash"  means that: there is no flash memory support on that
board. [You might argue that this should  actually  be  automatically
handled by U-Boot, i. e. defining both CFG_CMD_FLASH and CFG_NO_FLASH
on  one  board  should  throw an error condition. I will not reject a
patch that implements such checking, although I personally think this
is not needed.]


Now back to your  statement  of  having  "flash,  just  not  parallel
flash."  I know what you mean, but in the strict technical sense this
staement is wrong.  You  don't  have  flash  memory  (what  you  call
"parallel  flash"). We agree on that. But instead of simplyfying your
system description into "I have flash" you should correctly state:  I
have one or more flash storage devices (line NAND, Data Flash, etc.).

This is the crucial point of this discussion,  and  all  the  lengthy
previous  discussions  we  had about this: U-Boot memory commands and
U-Boot flash commands are intended to operate  on  memory,  including
flash  memory. The are NOT intended to operate on any kind of storage
devices. For storage devices a differen set of commands must be used.

I know, that the current code to support  Data  Flash  pretends  that
such  storage  devices  actually look like memory, but this is wrong.
And, as has been discussed several times before, this code shall  and
will  be  removed  from the U-Boot tree, and replaced by somthing new
which better represents tha actual nature and access  types  to  such
storage devices.

> Exactly, but there is flash, but not any *parallel* flash
> so the flash commands are needed, but not the stuff
> related to parallel flash.

Instead of trying to extend the current, deprecated implementation, I
would like to ask you to rather help to eliminate and replace it with
something better.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You cannot propel yourself forward by patting yourself on the back.

[U-Boot-Users] Running w/o flash

[Ulf Samuelsson]

Wolfgang Denk skrev:
> In message <460950A1.1060306@atmel.com> you wrote:
>> You believe that the code ifdef'ed away is neccessary
>> if you do not have any parallel flash?
> 
> No. The whole file is not compiled as it starts
> 
> 	#if (CONFIG_COMMANDS & CFG_CMD_FLASH)
> 
> If you have no flash, you need no flash commands, so you don't define
> CFG_CMD_FLASH and everything is fine.
> 

I have flash, just not parallel flash.
and I need the flash commands but not the stuff related to parallel flash.

>> They are not unneccessary, they are the first patches
>> of a set, which you are well aware that I would like to have
>> merged with the mainline.
> 
> I'm not sure what you mean. But if there is no flash, we  don't  need
> no flash commands either, no matter if these are empty or not. Agreed?

Exactly, but there is flash, but not any *parallel* flash
so the flash commands are needed, but not the stuff
related to parallel flash.

> 
> 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
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/20070327/b1325fbf/attachment.vcf 

[U-Boot-Users] Running w/o flash

[Wolfgang Denk]

In message <460950A1.1060306@atmel.com> you wrote:
>
> You believe that the code ifdef'ed away is neccessary
> if you do not have any parallel flash?

No. The whole file is not compiled as it starts

	#if (CONFIG_COMMANDS & CFG_CMD_FLASH)

If you have no flash, you need no flash commands, so you don't define
CFG_CMD_FLASH and everything is fine.

> They are not unneccessary, they are the first patches
> of a set, which you are well aware that I would like to have
> merged with the mainline.

I'm not sure what you mean. But if there is no flash, we  don't  need
no flash commands either, no matter if these are empty or not. Agreed?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Systems programmers are the high priests of a low cult.
                                                       -- R.S. Barton

[U-Boot-Users] Running w/o flash

[Ulf Samuelsson]

Wolfgang Denk skrev:
> In message <46094852.4080605@atmel.com> you wrote:
>> Yes, but there is still code compiled in which is not neccessary.
> 
> I disagree.
>

I do not understand!

You believe that the code ifdef'ed away is neccessary
if you do not have any parallel flash?

>> See patch: 24.noflash, just sent.
> 
> See my NAK to your patch which adds unnecessary empty functions.
> 

They are not unneccessary, they are the first patches
of a set, which you are well aware that I would like to have
merged with the mainline.


> 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
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/20070327/a319fdae/attachment.vcf