[U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Wolfgang Denk]

Dear Haavard Skinnemoen,

In message <20090901152305.68e8d339 at hskinnemoen-d830> you wrote:
>
> > On a 32 bit system with 36 bit physical addresses you cannot use a
> > physical address when running the "md" command, for example.
> 
> Yes you can, if you teach the "md" command to map it at a virtual
> address first. Again, map_physmem() makes this possible without
> changing the external interface in any way.

Well, that was the part of me saying before: "as long as it doesn't
hurt others". We don't want to add that complexity to U-Boot as noone
needs it.

The only few systems that seem to have problems are yours with their
exotic memory mappping.

> > > As far as I understand, the only difference for such systems is that
> > > keeping 64-bit physical addresses around are a bit more costly than
> > > passing around 32-bit virtual pointers. But presumably those systems
> > > have enough memory to make it a non-issue...
> > 
> > That's not true. There are 32 bit systems with bigger physical
> > address spaces. 
> 
> Which part of what I said isn't true? The part about some systems might
> require 64-bit variables to store a physical address or that such
> variables take more storage than a 32-bit virtual address?

Well, that the have enough memory not to case about size, for example.
[Keep in mind that this also effects the U-Boot image size in NOR
flash.]

> > We do not want to implement a full-fledged OS with virtual memory and
> > on-demand paging and all that stuff in U-Boot.
> 
> Then why are you forcing me to implement it for AVR32?!?

I'm not. I'm suggesting to implement a plain stupid 1:1 mapping and a
function to turn on and off data cache (at least on the flash area).

> > The advantage is that other drivers with similar needs can use it as
> > well.
> 
> But they can use map_physmem() today! It allows you to specify exactly
> what caching properties you need. The fact that it _may_ return a
> virtual address which is different from the physical one just allows
> more flexibility in how the architecture chooses to implement it!

You make assumptions on how other architectures work that may or may
not be true.

> > On other architectures it is not possible to map the same memory area
> > multiple times with different attributes.
> 
> So what? They can just return the physical address unchanged. It's not
> _mandatory_ to remap anything...

So how would these benefit from using data cache when reading from
flash? This works for you only because you are then reading from a
different address range.

> > It would be a good idea to clean up this board  support,  remove  the
> > proprietary  flash driver and use the CFI driver instead. Patches are
> > welcome.
> 
> You must be joking. Replacing a working driver with a broken one? Why
> the hell would anyone do that?

Fix the issues on the way?

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
Houston, Tranquillity Base here.  The Eagle has landed.
                                                    -- Neil Armstrong