82xxHCI driver for MPC8280 Specifically

Fri Nov 11 08:16:59 EST 2005

All,

I have been trying to get the 82xxHCI driver to work on our protoboard and
after a lot of correspondence with Freescale FAE's there are some real
differences in code implementation for some CPU parts.

Our board is using a MPC8280 Rev 0.1 part, the Rev number of course is the
last bit of the IMMR register. So 0xXXXX0A01 is our CPU, the 0A is all 8280
parts.

I was curious if anyone else has gotten this driver to operation
specifically on an 8280 CPU. Freescale says that ALL 8280's do NOT NEED any
microcode patch only some Rev's only need hardware workarounds to generate
the SOF packets, mainly wiring a BRG or TIMER to the DREQ1 / 4 lines at
least for Rev 0.0 and Rev 0.1. Rev A parts do not need this, as it is all
working internally, guess they finally fixed it.

This documentation is not conclusive as to how to wire and setup the DREQ
lines, and is no longer available on their websites, I have the PDF file
entitled MPC8280UMAD_D.pdf if anyone is curious about Rev 0.0 and Rev 0.1
parts.

So help, has anyone got this working with the Rev 0.0 and Rev 0.1 parts, and
if so, how? I have been spending way to much time reading and hacking code
to this barely functional. I would be happy to send anyone the code I have
currently, if they want to start in on this.

Russell McGuire

-----Original Message-----
From: linuxppc-embedded-bounces at ozlabs.org
[mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of
linuxppc-embedded-request at ozlabs.org
Sent: Thursday, November 10, 2005 6:52 AM
To: linuxppc-embedded at ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 15, Issue 21

Send Linuxppc-embedded mailing list submissions to
	linuxppc-embedded at ozlabs.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
	linuxppc-embedded-request at ozlabs.org

You can reach the person managing the list at
	linuxppc-embedded-owner at ozlabs.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linuxppc-embedded digest..."

Today's Topics:

   1. Re: [PATCH 2.6.14] mm: 8xx MM fix for (David Jander)
   2. PowerPC reservations (Kalle Pokki)
   3. Re: "Now booting the kernel" (Nathael PAJANI)
   4. floating point  + kernel (PPC) (srideep.devireddy at wipro.com)
   5. SCC QMC driver for 8247 (Robin Mathew)
   6. Re: "Now booting the kernel" (Nathael PAJANI)
   7. Re: [PATCH] ppc32 8xx: MPC8xx PCMCIA update (Dominik Brodowski)

----------------------------------------------------------------------

Message: 1
Date: Thu, 10 Nov 2005 10:18:07 +0200
From: David Jander <david.jander at protonic.nl>
Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
To: linuxppc-embedded at ozlabs.org
Message-ID: <200511100918.08060.david.jander at protonic.nl>
Content-Type: text/plain;  charset="iso-8859-1"

On Thursday 10 November 2005 08:48, David Jander wrote:
>[...]
> Hmmm. This is a lot in the line of the tests I did with (the more generic
> benchmark) nbench. After looking at those results (see my other post in
> this thread) I already suspected something like this.

Sorry, I obviously did not mean this thread, but the following post on
another 
thread:

http://ozlabs.org/pipermail/linuxppc-embedded/2005-November/020775.html

Regards,

-- 
David Jander

------------------------------

Message: 2
Date: Thu, 10 Nov 2005 10:20:30 +0200
From: Kalle Pokki <kalle.pokki at iki.fi>
Subject: PowerPC reservations
To: linuxppc-embedded <linuxppc-embedded at ozlabs.org>
Message-ID: <437302CE.8070309 at iki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

Can someone please help me understand how the memory reservations in 
PowerPC actually work. Let's just assume uniprocessor with a pre-emptive 
scheduler, and take a text-book example of an atomic increment case, 
which is also frequently used in e.g. the Linux kernel. With two atomic 
operations, everything seems to be just fine. But how about with three 
concurrent threads of execution?

 From the following code, assume r3 contains the same address for each 
incrementing operation. If the first atomic increment is pre-empted  in 
the middle, execution then jumps to the second increment (by the 
scheduler). The second increment runs through and succeeds, and 
continues straight to the third increment. Then it is again pre-empted 
in the middle, execution returning to the first increment. Now the 
processor has the reservation with the correct address, and the first 
increment succeeds when still holding the original input value. The 
first and the second increment thus write the same value in memory. 
After the first increment, the scheduler again continues the third 
increment, which doesn't succeed a first, but the second round succeeds. 
However, the value in the address pointed by r3 was not increased by 
three, but by two.

Am I just not getting how this is really supposed to work? Are there 
still some other constructs in use to prevent this, e.g. extra stwcx. 
instructions when changing the thread of execution?

I'm also wondering why the architecture specifically defines the stwcx. 
instruction to have, well, undefined behavior in case the reservation 
address differs from the address of the previous lwarx...

1:      lwarx r6, r0, r3
        addi r6, r6, 1
        stwcx. r6, r0, r3
        bne- 1b

.....

2:      lwarx r7, r0, r3
        addi r7, r7, 1
        stwcx. r7, r0, r3
        bne- 2b

3:      lwarx r8, r0, r3
        addi r8, r8, 1
        stwcx. r8, r0, r3
        bne- 3b

------------------------------

Message: 3
Date: Thu, 10 Nov 2005 11:40:14 +0100
From: Nathael PAJANI <nathael.pajani at cpe.fr>
Subject: Re: "Now booting the kernel"
To: linuxppc-embedded at ozlabs.org
Message-ID: <4373238E.8000405 at cpe.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

(Sorry, I first replyed with the wrong mail address)

 >Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
 >Uncompressing Linux...done.
 >Now booting the kernel

Hi!

At this state the bootloader stops executing and the Linux Kernel 
starts. The problem is that the Linux kernel does not know yet how to 
use the serial.

You won't have any message before it is set up (in early-console if my 
memory is allright)

So what you can do to check what's going on, is put "breakpoints" in the 
boot sequence. This means in the file arch/ppc/kernel/head*.S used for 
your board you should try to comment the line with the "tlbwe" 
instruction in the section "/* 2. Invalidate all entries except the 
entry we're executing in */"
This will allow you to keep access to your board registers.

Then you go step by step, putting some code which will reboot the board 
when executed, so you know you're going up to that point, and then move 
the "breakpoint" further.

This code does the reboot (for the booke I can reboot the board by 
writting '4' at address 0xfa001001):

ASM:
   lis r4,0xfa00
   li  r5,4
   stb r5,0x1001(r4)
   msync

C:
*((volatile unsigned char*)0xfa001001 = 4;

This way, instead of hanging up, the board reboots and you know where 
you are.

If you're going up to this:
         bl      machine_init    /* arch/ppc/kernel/setup.c */
         bl      MMU_init    /* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific, 
once again, check that the ones used (compiled) are those you need.

And next you've got the "start_kernel" call, which leads you to C code 
definitely. It's in init/main.c.

I hope I did not tell anything wrong, and that this will help.

Have fun.
Nathael.

------------------------------

Message: 4
Date: Thu, 10 Nov 2005 18:07:31 +0530
From: <srideep.devireddy at wipro.com>
Subject: floating point  + kernel (PPC)
To: <linuxppc-embedded at ozlabs.org>
Message-ID:
	<6AD9F6A5F6E096408F0B703773355A07605C40 at CHN-SNR-MBX01.wipro.com>
Content-Type: text/plain; charset="us-ascii"

Thanks for your help friends ...

     I am able to bring my kernel up ...... right now I have a problem
after some time at the console .... I get floating point used in kernel
(task=C0188480,pc=1100)

10.0.0.2 login: root

Last login: Tnhu Jan  1 00:00sole

Linux 10.0.0.2 2.4.22 #1 Tue Nov 8 12:03:26 UTC 2005 ppc unknown

MontaVista(R) Linux(R) Professional Edition 3.1

root at 10.0.0.2:~# <mailto:root at 10.0.0.2:~> 

root at 10.0.0.2:/home# cd ..

root at 10.0.0.2:/# ls

bin  boot  dev  etc  home  lib  mnt  opt  proc  root  sbin  tmp  usr
var

root at 10.0.0.2:/# floating point used in kernel (task=c0188480, pc=1100)

What does this mean ...? This makes the console hang .....Can any 1 help
me on in this?

Best Regards

srideep

Confidentiality Notice

The information contained in this electronic message and any attachments to
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
Mailadmin at wipro.com immediately
and destroy all copies of this message and any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051110/30c43a42/
attachment-0001.htm

------------------------------

Message: 5
Date: Thu, 10 Nov 2005 20:18:48 +0530
From: Robin Mathew <robin at india.tejasnetworks.com>
Subject: SCC QMC driver for 8247
To: Linuxppc-embedded <linuxppc-embedded at ozlabs.org>
Cc: Nicholas Basker <nbasker at india.tejasnetworks.com>
Message-ID: <43735DD0.9030205 at india.tejasnetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hello:

We are working on implementing driver for SCC operating in QMC mode that 
supports multiple HDLC channels. The details of the system we are using 
are the following.

CPU Version = 8247 based on 82xx family of processor(PVR 80822014)
The Linux OS Version = DENKS Linux version 2.4.20.
The Peripherals used are = FCC1 in 10/100 ethernet
                                            FCC2 in 10/100 ethernet
                                            SCC1 currently not used, but 
proposed to be used in HDLC mode.
                                            SCC3 is not used.
                                            SCC4 operating in QMC mode 
with super -channel capability. Trying to operate 192kbps HDLC channel 
(using 3x64kbps QMC channels).
                                            SMC2 in UART mode (as a 
simple debug port without any modem signals).
                                            SPI interface currently not 
used but shall be used in future.
                                            I2C is being used.

01. Can the channel specific parameters of the SCC4 in QMC mode be 
relocated from DPRAM base address?? There is no mention in the 
8272RM.pdf about configuring the base address of channel specific 
parameters. From the QMC memory structure diagram, it looks like the 
channel specific parameters will be taken from the the DPRAM base 
address. Can you please confirm it?

02. We have changed the function m8260_cpm_dpalloc() used for DPRAM 
allocation in the linux source code. It was allocating memory from 
128Byte location to 8KByte location in DPRAM. But since QMC requires the 
lower 4KByte for channel specific parameters, we changed the function to 
allocate DPRAM from 4KByte location. Will this change lead to any 
problem for proper linux operation?

03. We are encountering a strange problem with scc4 parameter RAM. When 
the driver is coming up, its trying to initialize the SCC4 parameter RAM 
for QMC. In the location (immr + 0x8318), we are writing the value 
0x8320 but the value magically changes to 0x8300. We tried to write to 
the location using BDI and again the problem is seen. Is this a known 
problem with the processor?? This problem doesnot appear everytime. Is 
there any known cause for this problem?

Regards,
Robin

------------------------------

Message: 6
Date: Thu, 10 Nov 2005 09:46:30 +0100
From: Nathael PAJANI <nathael.pajani at ecrin.com>
Subject: Re: "Now booting the kernel"
To: linuxppc-embedded at ozlabs.org
Message-ID: <437308E6.2070804 at ecrin.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 >Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
 >Uncompressing Linux...done.
 >Now booting the kernel

Hi!