Chris Skepper wrote:
Thanks so much for your help so far. I was able to find out this
address from the bootloader and get some output on the early debug
console which was very pleasing. It now gets as far as console_init()
called from init/main.c, which completes but then any printk seems to
On Wed, 27 Aug 2008, Scott Wood wrote:
On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote:
I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2?
Is that likely to be correct for SMC1? (I tried looking in the MPC8272
reference manual, but couldn't find it.)
Th
On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote:
> I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2?
> Is that likely to be correct for SMC1? (I tried looking in the MPC8272
> reference manual, but couldn't find it.)
The value depends on how the port was s
On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote:
> Is it likely the port isn't set up properly? udbg_early_init and
> udbg_init_cpm get called before it probes the machine so there's been no
> chance to do cpm2_set_pin or anything.
For the early console to work, the pins must have
On Tue, 26 Aug 2008, Scott Wood wrote:
It's usually easiest to just trust that that part of the code works (in
my experience, that's rarely where a hang actually occurs when bringing
up a new board), and resume tracing after the MMU is on and you've
inserted a caching-inhibited BAT entry.
Wher
Chris Skepper wrote:
On Tue, 26 Aug 2008, Scott Wood wrote:
On Tue, Aug 26, 2008 at 01:00:05PM +0100, Chris Skepper wrote:
I'm triggering an LED which is connected to port A. Are you saying that
wouldn't work once the caching is enabled?
It's quite possible. What other registers are in th
On Tue, 26 Aug 2008, Scott Wood wrote:
On Tue, Aug 26, 2008 at 01:00:05PM +0100, Chris Skepper wrote:
I'm triggering an LED which is connected to port A. Are you saying that
wouldn't work once the caching is enabled?
It's quite possible. What other registers are in the same cache line as
t
On Tue, Aug 26, 2008 at 01:00:05PM +0100, Chris Skepper wrote:
> >How are you determining that it never gets to that point? If it's via
> >serial I/O or similar, be aware that I/O isn't going to work when caches
> >are enabled but the MMU is not.
>
> I'm triggering an LED which is connected to
On Fri, 22 Aug 2008, Scott Wood wrote:
Chris Skepper wrote:
Using code to flash an LED I have traced execution from the entry point in
head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and into
setup_common_caches in cpu_setup_6xx.S. It appears to reset when enabling
the cache
I have a custom MPC8247 based board which has been running U-boot 1.3.5
and Linux 2.6.26. It has been working fine with ARCH=ppc, but I now want
to make it work using ARCH=powerpc.
However, using ARCH=powerpc I have encountered a problem. Whatever I do
it always appears to reset in the very e
Chris Skepper wrote:
Using code to flash an LED I have traced execution from the entry point
in head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and
into setup_common_caches in cpu_setup_6xx.S. It appears to reset when
enabling the cache on the CPU:
setup_common_caches:
mf
Hi all,
I have a custom MPC8247 based board which has been running U-boot 1.3.5
and Linux 2.6.26. It has been working fine with ARCH=ppc, but I now want
to make it work using ARCH=powerpc.
However, using ARCH=powerpc I have encountered a problem. Whatever I do
it always appears to reset in
12 matches
Mail list logo
