Dear Stefan,
in message <[EMAIL PROTECTED]> you wrote:
>
> > I don't like to see these either, but it's better than lying in the
> > face of the user.
>
> Please note that it is not so easy on 440 to even define *what exactly* the
> functions/commands d/icache_en/disable mean. This is because 440 has MMU
> support and we can have different cache setups for all TLB entries. So to
> which TLB entries should these functions refer? Just those mapping SDRAM?
> And/or FLASH? And/or internal SRAM? ...
You are the 440 expert, not me :-)
> > > you are you asking for additional changes too. Are you asking me to
> > > remove (a) all dummy cache entries or (b) to support *real* cache suppo>
> > > rt
> > > functions for 440? (a) would lead as explained above to bigger code
> > > changes in the common code and (b) is extremely difficult and I just ha>
> > > ve
> > > no time for such a thing currently.
> >
> > Yes, let's do either (a) or (b). There is no other choice.
>
> From my point of view, both "solutions" should not be done outside of a
> merge-window. I'll try to find some time to implement on of those options in
> the next weeks. But perhaps somebody else has more "free time" and sends
> patches to implement (and test) this stuff.
I agree that it is probably not possible to fix this right now,
especially since the actual problem is older, it just became visible
now.
But I insist that this must be fixed for the next release - and
actually it seems to be a good thing to really enable the instruction
cache - this would allow to speed up booting on 440 systems quite a
bit.
> > This still leaves the problem of the current "implementation" of the
> > other stubs. Please note that as is, we even have *random* behaviour
> > of the code, as the functions are supposed to return the cache
> > status, but no return value gets loaded.
>
> I don't see such a problem with *random* behavior. d/icache_status return 0
> on
> 440.
Ah, you are right. I thought that the {i,d}cache_{en,dis}able()
functions returned a status, but they are indeed void. Sorry for the
false alarm.
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: [EMAIL PROTECTED]
There's no sense in being precise when you don't even know what
you're talking about. -- John von Neumann
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
