Sorry, I just figured it was a generic problem with anything that used a data-cache that didn't write out to memory completely until flushed.
It is a Xilinx FX12 power pc system on a board which is not yet in the u-boot code base. It is similar to a Xilinx ML403 board. It does use the data-cache for the ram address area.
#define CONFIG_405 1 /* This is a PPC405 CPU */ #define CONFIG_4xx 1 /* ...member of PPC4xx family */
I'll also mention my initial image for my hello_world was only 350 bytes.
In my case a flush worked since I had never executed code in that address space. I would assume that the instruction cache should possibly be invalidated in case some other code had been loaded previously into this new images address space.
Let me know if you need more information. This is my first endeavor into this low level software so I probably don't know all that is required by you to solve the problems.
cc: u-boot-users@lists.sourceforge.net From: Wolfgang Denk wd@denx.de Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Date: Mon, 23 Oct 2006 22:13:06 +0200
In message E4F85F038628374E99FC45E3040C619B026F3175@us-bv-m22.global.tektronix.net you wrote:
I was tring to get a bootm command to work and had a problem until I called the fluch_cache routine to force the results of the data move into ram. This way the execution of the image used the code I had moved into ram rather then whatever was sitting there.
And you expect us to guess which architecture / processor / board you are talking about?
------_=_NextPart_001_01C6F6DE.77ED452B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please NEVER post HTML on this list!
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de For those who like this sort of thing, this is the sort of thing they like. - Abraham Lincoln