@lists.denx.de
Date: 2010/11/15 17:58
Subject: Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
Sent by: u-boot-boun...@lists.denx.de
The experts found an issue within init code and it looks like a proper
patch will be added to mainline shortly.
The discussion of the proper fix is right
After adding some more stuff in start.S I find that a lwz isn't
enough. An extra isync fixes this though
lwz r4, LBLAWAR1(r3)
isync
So something is missing but what? I guess isync isn't it either but
it works for now.
Joakim,
Please post more code to the list to have a better understanding
, Phillips Kim-R1AAHA
r1a...@freescale.com, Gala ga...@kernel.crashing.org, U-Boot List
u-boot@lists.denx.de
Date: 2010/11/15 17:58
Subject: Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
Sent by: u-boot-boun...@lists.denx.de
The experts found an issue within init code and it looks
...@freescale.com, ku...@theia.denx.de, Tabi
Timur-B04825 b04...@freescale.com, Phillips Kim-R1AAHA
r1a...@freescale.com, Gala ga...@kernel.crashing.org, U-Boot List
u-boot@lists.denx.de
Date: 2010/11/15 17:58
Subject: Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
Sent by: u-boot-boun
Scott Wood scottw...@freescale.com wrote on 2010/11/17 20:03:25:
On Wed, 17 Nov 2010 18:26:02 +0100
Joakim Tjernlund joakim.tjernl...@transmode.se wrote:
Scott Wood scottw...@freescale.com wrote on 2010/11/17 18:05:37:
On Wed, 17 Nov 2010 17:57:53 +0100
Joakim Tjernlund
On Wed, 17 Nov 2010 20:15:01 +0100
Joakim Tjernlund joakim.tjernl...@transmode.se wrote:
Scott Wood scottw...@freescale.com wrote on 2010/11/17 20:03:25:
The load, conditional branch, isync sequence is documented in the
architecture manual (1.7.1), even if the effects of the 'dependency'
Scott Wood scottw...@freescale.com wrote on 2010/11/17 20:27:01:
On Wed, 17 Nov 2010 20:15:01 +0100
Joakim Tjernlund joakim.tjernl...@transmode.se wrote:
Scott Wood scottw...@freescale.com wrote on 2010/11/17 20:03:25:
The load, conditional branch, isync sequence is documented in the
On 11/12/2010 08:31 PM, Scott Wood wrote:
On Fri, 12 Nov 2010 13:26:17 -0600
Kumar Galaga...@kernel.crashing.org wrote:
On Nov 12, 2010, at 11:22 AM, Scott Wood wrote:
On Fri, 12 Nov 2010 09:58:53 -0600
Kumar Galaga...@kernel.crashing.org wrote:
We only do the 'twi'
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/11/15 10:57:30:
On 11/12/2010 08:31 PM, Scott Wood wrote:
On Fri, 12 Nov 2010 13:26:17 -0600
Kumar Galaga...@kernel.crashing.org wrote:
On Nov 12, 2010, at 11:22 AM, Scott Wood wrote:
On Fri, 12 Nov 2010 09:58:53 -0600
Has anyone else tested 83xx on NOR?
My guess is that cache line crossing shifted so that now the CPU
doesn't need to read in a new cache at the critical part.
I notice this is hot thread for 83xx in these days.
Anybody can share more background for the issue?
I would like have a look the
Dave,
I notice this is hot thread for 83xx in these days.
Anybody can share more background for the issue?
I would like have a look the issue.
during MPC8377 board bring up we couldn't get U-Boot up and running -
the serial line has been dead.
Using a bdi2000 debugger told us the CPU,
The experts found an issue within init code and it looks like a proper
patch will be added to mainline shortly.
The discussion of the proper fix is right in this thread ...
It should be timing issue in the SoC, software did not have a proper
process to handle
IMMR registers accessing.
I agree
The experts found an issue within init code and it looks like a proper
patch will be added to mainline shortly.
The discussion of the proper fix is right in this thread ...
It should be timing issue in the SoC, software did not have a proper
process to handle
IMMR registers accessing.
[Responding here rather than directly to Dave since his e-mail showed
up blank here for some reason]
On Mon, 15 Nov 2010 18:30:46 +0100
Joakim Tjernlund joakim.tjernl...@transmode.se wrote:
The experts found an issue within init code and it looks like a proper
patch will be added to
Wouldn't the fact that you're accessing the same address -- and
that it's cache inhibited -- eliminate the need for a sync instruction
between the stw and lwz?
You are right. If st and ld the same address, e300 core have a address
collision inside.
It will make sure the order. Here we don't
Timur Tabi wrote:
Wood Scott-B07421 wrote:
To be totally safe, we probably want to do a readback plus twi (to turn
a data dependency into a flow dependency) before the isync.
twi == trap word immediate?
Yes.
If so, I don't see how that will turn a data dependency
On Nov 4, 2010, at 9:45 AM, Joakim Tjernlund wrote:
After the removal of COLD/WARM start flags my mpc8321
board didn't boot anymore.
Trial and error suggests that map_flash_by_law1 needs
an isync(padding with 4 nop's also did the trick)
after updating LBLAWAR1 to make sure the the change
On Fri, 12 Nov 2010 09:58:53 -0600
Kumar Gala ga...@kernel.crashing.org wrote:
On Nov 4, 2010, at 11:47 AM, Wood Scott-B07421 wrote:
Joakim Tjernlund wrote:
Trial and error suggests that map_flash_by_law1 needs
an isync(padding with 4 nop's also did the trick)
after updating LBLAWAR1
On Nov 12, 2010, at 11:22 AM, Scott Wood wrote:
On Fri, 12 Nov 2010 09:58:53 -0600
Kumar Gala ga...@kernel.crashing.org wrote:
On Nov 4, 2010, at 11:47 AM, Wood Scott-B07421 wrote:
Joakim Tjernlund wrote:
Trial and error suggests that map_flash_by_law1 needs
an isync(padding with 4
On Fri, 12 Nov 2010 13:26:17 -0600
Kumar Gala ga...@kernel.crashing.org wrote:
On Nov 12, 2010, at 11:22 AM, Scott Wood wrote:
On Fri, 12 Nov 2010 09:58:53 -0600
Kumar Gala ga...@kernel.crashing.org wrote:
We only do the 'twi' for loads/in_beX not stores/out_beX.
Yes, and the
Timur Tabi wrote:
Wood Scott-B07421 wrote:
To be totally safe, we probably want to do a readback plus twi (to turn
a data dependency into a flow dependency) before the isync.
twi == trap word immediate?
Yes.
If so, I don't see how that will turn a data dependency into a flow
On 11/04/2010 08:49 PM, Wood Scott-B07421 wrote:
Timur Tabi wrote:
Wood Scott-B07421 wrote:
To be totally safe, we probably want to do a readback plus twi (to
turn
a data dependency into a flow dependency) before the isync.
twi == trap word immediate?
Yes.
If so, I don't see
Joakim Tjernlund wrote:
Trial and error suggests that map_flash_by_law1 needs
an isync(padding with 4 nop's also did the trick)
after updating LBLAWAR1 to make sure the the change has
reached the HW before continuing with the code that depends on it.
Add an isync to remap_flash_by_law0 for
Wood Scott-B07421 wrote:
To be totally safe, we probably want to do a readback plus twi (to turn
a data dependency into a flow dependency) before the isync.
twi == trap word immediate?
If so, I don't see how that will turn a data dependency into a flow dependency.
Is that some sort of side
Wood Scott-B07421 b07...@freescale.com wrote on 2010/11/04 17:47:41:
Joakim Tjernlund wrote:
Trial and error suggests that map_flash_by_law1 needs
an isync(padding with 4 nop's also did the trick)
after updating LBLAWAR1 to make sure the the change has
reached the HW before continuing
Timur Tabi wrote:
Wood Scott-B07421 wrote:
To be totally safe, we probably want to do a readback plus twi (to turn
a data dependency into a flow dependency) before the isync.
twi == trap word immediate?
Yes.
If so, I don't see how that will turn a data dependency into a flow
26 matches
Mail list logo
