Dear Haavard Skinnemoen,
In message <20090901152305.68e8d...@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: w...@denx.de
Houston, Tranquillity Base here. The Eagle has landed.
-- Neil Armstrong
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
