On Fri, 16 Jul 2010 17:30:01 -0700
Shawn Jin wrote:
> >> > My RCCR=0x1, meaning the first 512B is for microcode. So the data and
> >> > the TxBD should really be starting at 0xfa202200? Then my muram data's
> >> > reg should be <0x200 ?>? What size shall I specify?
> >>
> >> After the muram data'
>> > My RCCR=0x1, meaning the first 512B is for microcode. So the data and
>> > the TxBD should really be starting at 0xfa202200? Then my muram data's
>> > reg should be <0x200 ?>? What size shall I specify?
>>
>> After the muram data's reg is changed to <0x200 0x1a00>, the cpm_uart
>> driver works
On Fri, 16 Jul 2010 00:12:21 -0700
Shawn Jin wrote:
> >> Why would the TxBD be filled with all 0xF? Would it be possible that
> >> the bdbase actually points somewhere else other than the TxBD?
> >
> > The virtual address 0xfddfa000 is mapped to 0xfa202000. I suspect that
> > the TxBD of my MPC87
>> Why would the TxBD be filled with all 0xF? Would it be possible that
>> the bdbase actually points somewhere else other than the TxBD?
>
> The virtual address 0xfddfa000 is mapped to 0xfa202000. I suspect that
> the TxBD of my MPC870 may not start at 0xfa202020.
>
> I notice that for adder875, e
> The problem is that after/when the kernel switches to the real console
> from the boot console, printk() calls cpm_uart_console_write() to
> print the first (?) message using the cpm_uart driver. But the
> transmitter buffer never becomes ready. It's shown below with the gdb
> session.
>
> Progra
Hi Gurus,
Please give me some hints and directions to debug this problem. I've
been scratching my head for quite a while.
The problem is that after/when the kernel switches to the real console
from the boot console, printk() calls cpm_uart_console_write() to
print the first (?) message using the
