1MB alignment dma_alloc question
Anyone, Putting together a driver, IMA for ATM in a MPC83xx. Anyway the manual states that one of the data structures for the QE needs to be allocated on a 1MB boundary in external memory. Normally these come in 128/64/32byte boundaries and are easy to self align, with some bit logic. However, after reading up on dma_alloc_coherent I see that a limitation is that dma cannot span 64K page boundaries. So this begs a question is their a better way to get a 1MB aligned table? Other than allocating almost 2MB of memory and then trying to mask off the LSBs? Seems like an awful waste of memory. I guess the real question is there a better kernel call that returns already aligned DMA memory? Thanks, -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: How many super channels per TDM on MCC
Jampala, I think the bit part you are missing is the SI and TSA assignment in the 82xx family manual. This is how the associations are created; we should really step away from the TDM and Super channel relationship as it is just a catch all for a port that is interfaced with the SI TSA. You need to focus on how you are breaking down your TDM stream with the SI TSA interface. Your question should be: How are super channels and the SIxRAM entries related? How big should I make my timeslots? 8 bits? 4 bits? 1 bit? Assuming basic ideas: * Your TDM is running at 2Mhz for E1 rates. * You have a line protocol with a sync pulse every SFrame or ESFrame. * Divided your SIxRAM into 32 entries to parse your TDM. * 8 bit time slots works for channelized and clear channel. * One SI entry per time slot * 4 time slots routed to each super channel This would indicate that you can only get 4 super channels per TDM @ 2Mhz and ESF. As your TDM doesn't carry any more data, assuming you running a single E1 into a TDM interface. Now if you have scaled up your clock rate, from E1 rates to say 8Mhz. Then this all changes. IF * Your TDM is running 8 Mhz <4 E1s combined into a single TDM> * You can still sync on your ESF Frames. * You Will need to figure out some way to sync you individual ESF frames within your 8Mhz stream. Not sure on your HW, is it one sync pulse for every ESF? Or one sync pulse for every four muxed ESFs? * Your SixRAM entry might still have the same entries, but just be repeated 4x faster, good luck figuring out which time slot 1 is from which original E1 Phy. OR * You might have to create 128 SI entries to handle all the time slots. In this case you might have to consider using shadow entries and loops with the SI. Assuming only one sync pulse for all ESFs grouped together. IN this case you could get 4 time slots per super channel and have 24 super channels running on a single TDM. As a side note there is a WhitePaper from Freescale that talks about a similar scenario on the 8360E. You might check that out, i.e. hooking 16 T1/E1's into a system through a TDM backplane. In their case they only route 2 E1's per TDM though. Same rules would apply. > -Original Message- > From: bhanu jampala [mailto:[EMAIL PROTECTED] > Sent: Friday, August 29, 2008 1:53 PM > To: linuxppc-embedded@ozlabs.org > Cc: [EMAIL PROTECTED]; Robert Staven; Scott Wood > Subject: How many super channels per TDM on MCC > > Hi Guys, > > This is regarding MCC controller on MPC8260. > I am having problems figuring out how super channels fit into a TDM. > > A superchannel is the combination of multiple MCC TX channels' FIFOs and > one > set of an MCC channel's parameters and buffer descriptors. > > If I want to support 24 super channels with 4 timeslots each. > Can I use a single TDM (i.e. from A,B ,C, D) to accomplish this task. > (each TDM has 32 timeslots). > > - Mukund Jampala ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
virt_to_phys() in drivers w/dma - MPC8xxx
A style / function question. I have been seeing conflicting articles and examples on what the proper method would be for some of the Freescale MPC drivers. I am putting together an ATM driver, and 'might' be having some erratic results due to this function. Not sure yet, but wanted to put this out there for comments. In many cases when dealing with TxBD or RxBD pointers a UCC or what not driver will use the virt_to_phys() call to get what I assume is a physical address that can be used for dma? Perhaps not in all cases, but a majority. See ucc_geth.c for an example of the usage. I have also seen some prototype drivers that use this call to get the physical address to place into the QE_MURAM for the PRAM initialization. I then ran across this link: http://mirror.linux.org.au/linux.conf.au/2005/cdrom-beta-1/linux-mandocs-2.6 .12.6/virt_to_phys.html Which states: The returned physical address is the physical (CPU) mapping for the memory address given. It is only valid to use this function on addresses directly mapped or allocated via kmalloc. This function does not give bus mappings for DMA transfers. In almost all conceivable cases a device driver should not be using this function. --- So shouldn't we be using like dma_alloc_coherent, and then tracking the dma address separately as a variable, and use it when necessary instead of calling virt_to_phys()? Or am I confused on what these are doing? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
ELDK Fedora Core 9
Guys, I know that DENX doesn't list ELDK 4.1 with FC9 as officially supported, but has anyone tried to install it with FC9? Attempts last night resulted in the install script freezing during install, and no apparent error messages. 1) Has anyone tried this? Success? 2) Does anyone have suggestion on how turn on debugging with the install script? Thanks -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
82xx/83xx MCC Super Channels - GUN Error
Guys, Attempting to polish up an existing MCC HDLC driver, adding super channels for an 8360E, though I imagine the specifics an answer, might work for any 82xx or 83xx architecture. Background: I have taken my existing working MCC HDLC driver interfaced to a T1 in clear channel mode, and found that I was using less than optimized MCC configuration, i.e. using the TX SiRAM entries to transmit 8 bytes chunks. Though his works, I get GUN errors probably every 10 minutes. So after careful reading, I decided to optimize and create super channels using the 83xx version <16 bit entries only for 83xx> for the SiRAM. Problem: After the super channel conversion, I now get GUN interrupts continuously the instant I enable the TDM's / SI. Detail: I have written the extra code to program up the SiRAM entries, RX side to use super channel 6 , and the TX side uses channels 0-11 <12 channels of 2 bytes = 192 byes of a standard T1 B8ZS-ESF Frame>, my SCT table of course routes slots 0-11 into SC 6. I am guessing this is correct, and more likely I probably have a setup problem with configuring all the MCC parameters, or init sequence. After reading much Freescale documentation and their FAQ's online, I see there are a couple of undocumented things that may or may not need to be done, like stopping a super channel before issues the QE_INIT_TX_RX commands. So my question is this: In order to not have GUN always occurring, how does one initialize a super channel and its related sub-channels? This what I am doing now. 1) Program SI entries 2) Program MCC global PRAM? 3) Program SuperChannel ChanPRAM 4) Program SuperChannel XtraPRAM 5) Program SuperChannel Table 6) Set rstate and tstate once for SuperChannel i.e. channel 6 7) Call QE_INIT_TX_RX once for channel block 0 . 8) Enable TDM's 9) GUN recovery code goes nuts until I reset. Anybody have experience with this and super channels? I have seen hints that perhaps I need to maybe set rstate and tstate for every channel in the super channel, what about the 'first byte' in the SiRAM TX entry? Does that need to be set for clear channels? I have seen one email for 82xx MCC that say the super channel needs to be QE_STOP_TX before calling the MCC INIT code, but not sure if that is really needed, or only for 82xx CPU's. What about using the QE_INIT_TX_RX_16? I have tried this, and it causes silence in the driver, i.e. can't even get interrupts if I use this command. Ideas anyone? Russell McGuire Senior Systems Engineer [EMAIL PROTECTED] 503.888.0968 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH]: Freescale UCC_GETH Half Duplex
All,
This fix is for UCC_GETH, in the manual only TWO modes allow half duplex
setting, and this is for MII and RMII. All other modes are disallowed
because it is not supported in the Freescale MAC interface, and will throw
the QE engines into unknown states.
For all other modes other than MII and RMII, this doesn't mean that half
duplex doesn't work, it just means the bit can't be set, apparently ?, in Gigabit modes, like RGMII and GMII the MAC will
auto-detect if half duplex is in effect. Hence why we leave it set to dull
duplex.
Signed-off-by: Russell McGuire <[EMAIL PROTECTED]>
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 9a38dfe..5900847 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1533,10 +1698,17 @@ static void adjust_link(struct net_device *dev)
* If not, we operate in half-duplex mode. */
if (phydev->duplex != ugeth->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
- tempval &= ~(MACCFG2_FDX);
- else
- tempval |= MACCFG2_FDX;
+ /* Can only set half duplex for these two modes!! */
+ if ((ugeth->phy_interface == PHY_INTERFACE_MODE_MII)
||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RMII))
{
+ if (!(phydev->duplex))
+ tempval &= ~(MACCFG2_FDX);
+ else
+ tempval |= MACCFG2_FDX;
+ } else {
+ /* Always set for other modes */
+ tempval |= MACCFG2_FDX;
+ }
ugeth->oldduplex = phydev->duplex;
}
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Freescale UCC_GETH Half Duplex Patch
Kim, ALL Here is a fix up for the UCC_GETH driver supporting half duplex mode for some specific modes. I have tested this quiet extensively and the link now comes up and works, however not sure if there are other issues that need to be looked at, since 10BaseT connectivity provides VERY ERRATIC throughput, but at least it works now with RGMII and GMII modes. There was a lot more in my patch, but I removed a lot of the code for submission. Let me know if for any reason this patch file is improperly formatted. Russell McGuire Senior Systems Engineer [EMAIL PROTECTED] 503.888.0968 ucc_geth.patch Description: Binary data ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
The question about the QUICC ENGINE microcode for freescale
Couple of thoughts, is that according to Freescale specs, the QE can only support TWO 1000Mbit end points. And that is assuming RAW traffic, not protocol layer processing. Since the 8360E has two QUICC Engines, that is only 1000Mbits data per Engine. Are you intending to get 1000Mbits TX and RX on each engine? I think in reality you will be capped at 1000Mbit aggregate in the RX and TX. I could be wrong, but you might want to run that past a Freescale FAE, do you have the name of your contact for your area? This is assuming that you are running at the full speed of the MPC8360E, i.e both QUICC engines probably pushing 500Mhz. You'll also need to probably be running DDR2 RAM at MAX speed to achieve these rates, as each skbuf will have to be dma'd out to external memory. All the early dev boards by Freescale only used DDR1. As well you'll want to be sure your Coherent System Bus speed is as near max, i.e. 300-333Mhz. What clock speeds / Frequency of chip are you using to test this? As well which driver are you using with this test? As a HW designer for these boards and driver programmer I am just curious what your HW is looking / configured like? -Russ Hi,friends, I want to realize the high speed TCP package on GETH of MPC8360E,I would like the speed on both UCC1 and UCC2 for both send and receive TCP package(big package) up to 1000M bits/sec, so the total internet speed is 4000M bits/sec for MPC8360E. I tested the internet performance by IPERF test software with the condition that the core cpu deal with the TCP package,without microcode. I config the UCC2 down, config UCC1 to send package out to an server PC,no receive,the speed for UCC1 just only sending package is about 300M bits/sec, and CPU is 100% used. This speed is so slow, is too slow. If I send and recieve at the same time, the speed is much slower, if I make the UCC2 up, the speed is much slower and slower. I do not know how to incrase the internet speed for MPC8360E, somebody told me, we must use the microcode for QUICC ENGINE. My question is that where can I download the microcode for QUICC ENGINE and how to use it? Whether or not this microcode can help me to realize the 4000M bits/sec for TCP package? ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RAW Sockets - HDLC or Ethernet
Anyone, Yet another mysterious question, at least to me. I have written to simple utilities to send and receive a file / data through a newly created driver, HDLC using an MPC8360E. Though I doubt this question is limited to that specific HW. The main question is that everything I send though device HDLC0 I can immediately read from HDLC0 even though logically there is no connection there. It as if the kernel is immediately allowing me to read from the same device, what a separate application just wrote.??? HOW CAN THIS BE? Details: I have two applications: send and receive. (pseudo code as follows) Send opens a socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)). And binds it (AF_PACKET, ETH_P_HLDC, if_index(hdlc0)) Receive opens a socket to the same device socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) bind(AF_PACKET, ETH_P_ALL, if_index(hdlc0) Note they are opening the same device. Now if I send anything through the send application, I immediately receive it via the receive application?? Note, entirely separate processes! Note, there is NO hardware loopback, this should be a dead end, and I should get nothing back at least as far as HW is concerned. What am I missing, that causes all my TX data to show up immediately in the RX app? Note I have verified my HDLC drier is not actually receiving anything, so is there something in the kernel that is bridging the TX / RX paths, or am I just missing the function of this? If so how can I use RAW mode, while not mixing this, or at least keeping them separate in the applications? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Virtual device hdlc0 asks to que packet!
Jocke, I wonder how one change this? I don't remember any of the API calls referencing this, so maybe the default to 1000? Or perhaps that is protocol specific. I will hunt through some of Freescale's Ethernet drivers and see if I can't find anything. I know that inside the driver, I have 32 RX, and 32 TX buffers available. There needs to be some smarter way to manage it though than raw numbers. Large file transfers, if they are cached, can easily over flow any number of buffers. Thanks for the note. -Russ > -Original Message- > From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 05, 2008 12:12 AM > To: [EMAIL PROTECTED] > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: Virtual device hdlc0 asks to que packet! > > > On Tue, 2008-03-04 at 15:33 -0800, Russell McGuire wrote: > > All, > > > > Background MPC8360, using a T1 PHY as an HDLC device. > > > > Developing my hdlc driver, and was writing a simple send utility. To > test it > > out. Things seem well when I had massive delays in between the write() > or > > sendot(), and I was able to attain 100+Kbytes/sec. However, when I > replaced > > the simple usleeps(xxx) with select statements, suddenly I started > getting a > > ton of these messages. > > > > "Virtual device hdlc0 asks to que packet!" > > > > Along with dropped or non-sent data. > > > > In my driver I am tracking the available TX buffers, and issue a > > netif_stop_que() statement inside the start_xmit() call, with a > > corresponding netif_wake_que() in the tx_handler. > > > > Is there something else that needs to be done in order to make a select > > statement wait for the socket to not be busy? It seems that it always > > returns immediately with no timeout. > > > > I guess the other pieces of the scenario are as follows: > > > > * Using 'sethdlc hdlc0 hdlc' for the mode, so no IP stack is used. > > * Opening the socket to the hdlc device directly to the device itself, > i.e. > > no port number socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); > > > > I have used both sendto() and write() to pass data down, and they both > > return as if all the data has been sent, i.e. I never get an error. > > > > -Russ > > When playing with your driver I noticed that the hdlc interfaces had > txqueuelen:0 > Normal eth interfaces has txqueuelen:1000. Maybe you need to add a > txqueue to the hdlc interfaces? > > Jocke > > PS. > The driver seems to work now, I get both TX and RX IRQs now. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Virtual device hdlc0 asks to que packet!
All, Background MPC8360, using a T1 PHY as an HDLC device. Developing my hdlc driver, and was writing a simple send utility. To test it out. Things seem well when I had massive delays in between the write() or sendot(), and I was able to attain 100+Kbytes/sec. However, when I replaced the simple usleeps(xxx) with select statements, suddenly I started getting a ton of these messages. "Virtual device hdlc0 asks to que packet!" Along with dropped or non-sent data. In my driver I am tracking the available TX buffers, and issue a netif_stop_que() statement inside the start_xmit() call, with a corresponding netif_wake_que() in the tx_handler. Is there something else that needs to be done in order to make a select statement wait for the socket to not be busy? It seems that it always returns immediately with no timeout. I guess the other pieces of the scenario are as follows: * Using 'sethdlc hdlc0 hdlc' for the mode, so no IP stack is used. * Opening the socket to the hdlc device directly to the device itself, i.e. no port number socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); I have used both sendto() and write() to pass data down, and they both return as if all the data has been sent, i.e. I never get an error. -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: NETdev driver question xxxx_type_trans()
Andy, Thanks... I only have the hdlc_type_trans, on the RX side of the equation. I want the driver to be able to support two modes, so not sure if I am going to have to put an ioctl switch into to turn this on / off. Mode 1) I want the driver to be able to simulate an Ethernet device, which I assume will need to use the hdlc_type_trans(), to remove layer 2. Mode 2) I want the driver to be able to support fully RAW mode, but then again, perhaps the hdlc_type_trans() knows this already depending on what mode I am setup in, via 'sethdlc' ??? At the moment before I am able to use the device, I have to configure it via 'sethdlc hdlc0 hdlc-eth' or similar. <-- that previous call I assuming links it to the TCP/IP stack as I can assign IP addresses with "ifconfig hdlc0 up 192.168.1.100". However, for true P2P support, I was wanting to be able to open the device directly and manage everything directly at the application level, i.e. the only protocol would be "Application Layer->HDLC" and nothing in between. In that case, I was concerned that any removal of Layer 2 stuff, simply would be unnecessary as the 83xx already pulls the HDLC layer stuff off, before I get the sk_buff. port>. So not sure if the kernel will let me... But that is one of my goals. -Russ > -Original Message- > From: Andy Fleming [mailto:[EMAIL PROTECTED] > Sent: Friday, February 22, 2008 12:39 PM > To: [EMAIL PROTECTED] > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: NETdev driver question xxxx_type_trans() > > > On Feb 22, 2008, at 14:26, Russell McGuire wrote: > > > All, > > > > A general and specific question on the behavior of netdev devices > > before received sk_buff(s) get passed up to the kernel. > > > > I am almost done creating / testing an HDLC device driver for the > > 83xx. > > > > > > I have it working at a low level and was printing out skb_bufs > > before and after TX and RX, to ensure data integrity. > > > > Due to me having the print_skbbuf, AFTER the hdlc_type_trans(skb, > > ndev). > > > > I thought I was continuously losing 14 bytes of data, after a > > little digging I realized that the hdlc_type_trans() call > > > > was shifting the skb->data pointer forward by 14 bytes. > > > > Is this corresponding to a 14 byte pad that the kernel stack adds > > before it sends it down? > > > > And why isn't the data length being shortened as a result after I > > call hdlc_type_trans? > > > > Anyway. I guess I am confused as to what this function was intended > > for, I see there are other calls for eth_type_trans, so I imagine > > their usage is similar. > > > > When are they needed? > > > > > They move the data pointer to point to the start of the L2 header. > There's no need for the kernel to see the L1 header, and it doesn't > expect it to be there when it looks at the skb. > > You shouldn't be using it for TX packets. For TX, I believe the > kernel takes care of setting up the L1 header, though I'm not > familiar with the kernel's hdlc support. > > Andy ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
NETdev driver question xxxx_type_trans()
All, A general and specific question on the behavior of netdev devices before received sk_buff(s) get passed up to the kernel. I am almost done creating / testing an HDLC device driver for the 83xx. I have it working at a low level and was printing out skb_bufs before and after TX and RX, to ensure data integrity. Due to me having the print_skbbuf, AFTER the hdlc_type_trans(skb, ndev). I thought I was continuously losing 14 bytes of data, after a little digging I realized that the hdlc_type_trans() call was shifting the skb->data pointer forward by 14 bytes. Is this corresponding to a 14 byte pad that the kernel stack adds before it sends it down? And why isn't the data length being shortened as a result after I call hdlc_type_trans? Anyway. I guess I am confused as to what this function was intended for, I see there are other calls for eth_type_trans, so I imagine their usage is similar. When are they needed? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
HDLC driver - dev_free_skb_irq causes Segfault
All, So I am in the process of debugging my newly established HDLC driver. More or less modeled after a simplified gianfar / ucc_geth idea. However, after loading, etc. and using the following commands -> insmod hdlc-8360.ko -> sethdlc hdlc0 hdlc-eth -> ifconfig hdlc0 up 192.168.1.100 All is well, and I am seeing IDL interrupts. Great. Now I go to ping an address like, ping 192.168.1.101 I can see that I get the start_xmit function, the IRQ from the QE comes back and reports the TXBD as successfully sent. Here is the problem, when I goto free the skb in the tx_handler, I get a 'Unable to Handle Kernel Paging Request for data at address 0x' Even though for the life of me, I can't see any pointers that are at address zero. I have checked the pointer value I am passing in, and indeed it is the exact same pointer I am receiving from the original start-xmit call.. Are we supposed to copy the skb? And free it immediately in the start_xmit? Some special way to store the pointer? I have tried txbd->buf = skb->data; txbd->buf = virt_to_phys(skb->data); etc.. and various other ways to save that I have seen in the gianfar and ucc_geth drivers. My tx_sk_buff** is identical as alloced the same way. Anyone have any ideas? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: 83xx immap_qe.h -> SIR type def error?
I should state, I am looking at the MPC8360ERM.pdf Rev 2.0
-Russ
> -Original Message-
> From: Russell McGuire [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 01, 2008 1:03 PM
> To: 'Kumar Gala'
> Cc: 'linuxppc-embedded@ozlabs.org'
> Subject: RE: 83xx immap_qe.h -> SIR type def error?
>
> Kumar,
>
> Yes in the main memeory map they are just listed as 1K RAM blocks.
> However, in the UM Section 36.6.1 .
>
> It gives the breakout for the RAM, which clearly indicates 16 bit fields.
>
>
> Access: Read/Write
> 0 1 2 3 4 5 6 7 10 11 13 14 15
> MCC SWTR SSEL 1 SSEL 2 SSEL 3 SSEL 4 SGS CSEL CNT BYT LST
> Figure 36-8. SI RAM Entry for UCC
>
> Honest, mistake as if I were writing the header file I'd not have time to
> ready all 2000+ pages of the UM. We find these only as somebody goes in an
> tries to use them.
> And I am guessing not a lot of customers use the SI block.
>
> -Russ
> > -Original Message-
> > From: Kumar Gala [mailto:[EMAIL PROTECTED]
> > Sent: Friday, February 01, 2008 6:56 AM
> > To: [EMAIL PROTECTED]
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: 83xx immap_qe.h -> SIR type def error?
> >
> >
> > On Feb 1, 2008, at 5:47 AM, Russell McGuire wrote:
> >
> > > All Freescale,
> > >
> > > Not sure if this is the place to post this, but I have run across
> > > what I
> > > consider to be a possible type error in the immap_qe.h file, for the
> > > asm/powerpc branch.
> > >
> > > In the file immap_qe.h
> > >
> > > /* SI Routing Tables */
> > > struct sir {
> > > u8 tx[0x400];
> > > u8 rx[0x400];
> > > u8 res0[0x800];
> > > }
> > >
> > > Shouldn't these types be defined as __be16 ?
> > >
> > > According to the Freescale manual this is a 16 bit field, not an 8-bit
> > > field.
> > >
> > > Spent an hour trying to figure out why I couldn't fill this field
> > > out with
> > > upper 8 bits last night.
> > >
> > > Thoughts?
> >
> > I'm guessing it was done this way since they are just looked as base
> > offsets. Where in the UM do you see anything about them being 16-bit
> > quantities? (I'm really know little about this).
> >
> > - k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: 83xx immap_qe.h -> SIR type def error?
Kumar,
Yes in the main memeory map they are just listed as 1K RAM blocks.
However, in the UM Section 36.6.1 .
It gives the breakout for the RAM, which clearly indicates 16 bit fields.
Access: Read/Write
0 1 2 3 4 5 6 7 10 11 13 14 15
MCC SWTR SSEL 1 SSEL 2 SSEL 3 SSEL 4 SGS CSEL CNT BYT LST
Figure 36-8. SI RAM Entry for UCC
Honest, mistake as if I were writing the header file I'd not have time to
ready all 2000+ pages of the UM. We find these only as somebody goes in an
tries to use them.
And I am guessing not a lot of customers use the SI block.
-Russ
> -Original Message-
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 01, 2008 6:56 AM
> To: [EMAIL PROTECTED]
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: 83xx immap_qe.h -> SIR type def error?
>
>
> On Feb 1, 2008, at 5:47 AM, Russell McGuire wrote:
>
> > All Freescale,
> >
> > Not sure if this is the place to post this, but I have run across
> > what I
> > consider to be a possible type error in the immap_qe.h file, for the
> > asm/powerpc branch.
> >
> > In the file immap_qe.h
> >
> > /* SI Routing Tables */
> > struct sir {
> > u8 tx[0x400];
> > u8 rx[0x400];
> > u8 res0[0x800];
> > }
> >
> > Shouldn't these types be defined as __be16 ?
> >
> > According to the Freescale manual this is a 16 bit field, not an 8-bit
> > field.
> >
> > Spent an hour trying to figure out why I couldn't fill this field
> > out with
> > upper 8 bits last night.
> >
> > Thoughts?
>
> I'm guessing it was done this way since they are just looked as base
> offsets. Where in the UM do you see anything about them being 16-bit
> quantities? (I'm really know little about this).
>
> - k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
83xx immap_qe.h -> SIR type def error?
All Freescale,
Not sure if this is the place to post this, but I have run across what I
consider to be a possible type error in the immap_qe.h file, for the
asm/powerpc branch.
In the file immap_qe.h
/* SI Routing Tables */
struct sir {
u8 tx[0x400];
u8 rx[0x400];
u8 res0[0x800];
}
Shouldn't these types be defined as __be16 ?
According to the Freescale manual this is a 16 bit field, not an 8-bit
field.
Spent an hour trying to figure out why I couldn't fill this field out with
upper 8 bits last night.
Thoughts?
Russell McGuire
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Errors with compiling sethdlc 1.18
Anyone tried to compile sethdlc lately? Is there a patch for the kernel <2.6.20+> we're supposed to apply before compilation? I have tried it both for DENX and Standard Fedora Core 5, neither will compile due to errors In the data structures, i.e. missing stuff. -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
83xx HDLC Driver Dev - Multiple PHYs?
All, I have gotten my HDLC driver up to the point where it can register itself with the Linux kernel. However now I am faced with a dilemma and style question, that is probably best answered by you driver developers that have more experience. I am putting support for multiple PHY's into the HDLC driver, but after converting it to use the of_device tree, and inserting a [EMAIL PROTECTED] for a single UCC HDLC driver, it occurred to me that if I insert more devices ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) that the driver will attempt to load multiple times. So here is the question. Solution 1: Should I develop the system to have a single [EMAIL PROTECTED] entry in the platform.dts file and have a field(s) like phy-count=<4>, to support multiple devices? And have each instance of the module contain private data for one UCC, interrupt handling, etc... OR Solution 2: Is there a way to have a module know if it has already been loaded, so it doesn't insert multiple times and then play the rest like Solution 3? OR Solution 3: Have phy-count=4; defined in the driver header, or a module parameter, and have a single module instance of the driver itself responsible for creating a single private data structure and setting up multiple UCC's and PHY's? This also feeds into a question on SET_NETDEV_DEV. How does it react to multiple net devices attached to a single base driver? -Russ > -Original Message- > From: Andy Fleming [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 29, 2008 2:33 PM > To: [EMAIL PROTECTED] > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: SET_NETDEV_DEV -> 83xx HDLC Driver?? > > > On Jan 25, 2008, at 20:43, Russell McGuire wrote: > > > All, > > > > I am partly done porting a combination of the 83xx ATM driver and > > dscc4 HDLC > > driver into a 83xx HDLC driver. > > > > However, encounter a call I don't truly understand. > > > > SET_NETDEV_DEV(dev, pointer_to_some_handle); > > > > I can see plenty of examples of this registering some kind of PCI > > device > > handle, however in this case I am not using a PCI device. So what > > should the > > pointer be? Or can this call be ignored, and if so what are the > > consequences? > > > > I see the some of the Freescale Ethernet devices don't use this call. > > > > Anyway, can somebody shed some light on if I am going to need this, > > or a way > > to get it to work, without creating a PCI device? > > > Look at gianfar.c (which uses a platform_device) or ucc_geth (which > uses an of_device). Which freescale devices don't use that call? > We'll fix them. > > Andy ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: SET_NETDEV_DEV -> 83xx HDLC Driver??
Andy, /drivers/net/fec_8xx Doesn't use the call, though I imagine it is legacy or only for older boards. Thanks for pointing me at the newer stuff, guess I had a brain cramp and didn't think to look there. Also makes much more sense now that the pdev->dev is not a PCI device but a Platform device. One question, since you've probably got more experience with this than I do. The gianfar, and ucc_geth drivers are not modules. Is there a problem with using these driver _probe_ functions in a module style driver? OR should I just change my driver over to be a platform style? As far as I can tell the HDLC driver I am trying to create for the 83xx is going to be somewhat similar to the Ethernet driver. Only I don't want it loaded as part of the kernel. -Russ > -Original Message- > From: Andy Fleming [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 29, 2008 2:33 PM > To: [EMAIL PROTECTED] > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: SET_NETDEV_DEV -> 83xx HDLC Driver?? > > > On Jan 25, 2008, at 20:43, Russell McGuire wrote: > > > All, > > > > I am partly done porting a combination of the 83xx ATM driver and > > dscc4 HDLC > > driver into a 83xx HDLC driver. > > > > However, encounter a call I don't truly understand. > > > > SET_NETDEV_DEV(dev, pointer_to_some_handle); > > > > I can see plenty of examples of this registering some kind of PCI > > device > > handle, however in this case I am not using a PCI device. So what > > should the > > pointer be? Or can this call be ignored, and if so what are the > > consequences? > > > > I see the some of the Freescale Ethernet devices don't use this call. > > > > Anyway, can somebody shed some light on if I am going to need this, > > or a way > > to get it to work, without creating a PCI device? > > > Look at gianfar.c (which uses a platform_device) or ucc_geth (which > uses an of_device). Which freescale devices don't use that call? > We'll fix them. > > Andy ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
SET_NETDEV_DEV -> 83xx HDLC Driver??
All, I am partly done porting a combination of the 83xx ATM driver and dscc4 HDLC driver into a 83xx HDLC driver. However, encounter a call I don't truly understand. SET_NETDEV_DEV(dev, pointer_to_some_handle); I can see plenty of examples of this registering some kind of PCI device handle, however in this case I am not using a PCI device. So what should the pointer be? Or can this call be ignored, and if so what are the consequences? I see the some of the Freescale Ethernet devices don't use this call. Anyway, can somebody shed some light on if I am going to need this, or a way to get it to work, without creating a PCI device? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Driver - HDLC 83xx QUICC Engine??
Jocke, I ran across this patch doing some looking around. It isn't in the kernel I downloaded a while ago and have been working with, and I am not sure of the real extents of its support. Maybe Kim or Kumar can fill us in, on if it is what we are looking for. http://patchwork.ozlabs.org/linuxppc/patch?id=7262 In any regards, it definitely looks like something we should be checking out. -Russ > -Original Message- > From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 15, 2008 4:19 PM > To: [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org > Subject: SV: Driver - HDLC 83xx QUICC Engine?? > > > -Ursprungligt meddelande- > > Från: [EMAIL PROTECTED] > [mailto:linuxppc-embedded- > > [EMAIL PROTECTED] För Russell McGuire > > Skickat: den 15 januari 2008 20:52 > > Till: linuxppc-embedded@ozlabs.org > > Ämne: Driver - HDLC 83xx QUICC Engine?? > > > > All, > > > > Does anyone know of a project or existing driver for supporting HDLC for > the > > > > MPC83xx or MPC82XX Freescale CPUs? > > > > Looking to run raw HDLC over various Ethernet or T1 links. > > > > -Russ > > Me too. Perhaps not, I will be looking at presenting a Ethernet i/f to the > kernel but > sending out HDLC frames containing the Ethernet packet. If you find/have > anything > that helps me do that, send it my way please. > > Jocke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Driver - HDLC 83xx QUICC Engine??
Jocke, I'll let you know if I find any. For a starting point, I have an QE ATM driver, that is more than likely similar in design , as it supports the QE engine, and just turns the UCC into ATM mode, as opposed to HDLC mode. Would imagine the buffering, IO, interrupts are similar. I am still in process of porting it up from the 82xx CPU. Although HDLC how it registers itself into the kernel is a mystery to me, I am having trouble finding any HDLC drivers to model this after. Know of any specs? API? Etc... -Russ > -Original Message- > From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 15, 2008 4:19 PM > To: [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org > Subject: SV: Driver - HDLC 83xx QUICC Engine?? > > > -Ursprungligt meddelande- > > Från: [EMAIL PROTECTED] > [mailto:linuxppc-embedded- > > [EMAIL PROTECTED] För Russell McGuire > > Skickat: den 15 januari 2008 20:52 > > Till: linuxppc-embedded@ozlabs.org > > Ämne: Driver - HDLC 83xx QUICC Engine?? > > > > All, > > > > Does anyone know of a project or existing driver for supporting HDLC for > the > > > > MPC83xx or MPC82XX Freescale CPUs? > > > > Looking to run raw HDLC over various Ethernet or T1 links. > > > > -Russ > > Me too. Perhaps not, I will be looking at presenting a Ethernet i/f to the > kernel but > sending out HDLC frames containing the Ethernet packet. If you find/have > anything > that helps me do that, send it my way please. > > Jocke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Driver - HDLC 83xx QUICC Engine??
All, Does anyone know of a project or existing driver for supporting HDLC for the MPC83xx or MPC82XX Freescale CPUs? Looking to run raw HDLC over various Ethernet or T1 links. -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: 83xx, ucc_geth, kernel 2.6.23, IP-Config: No network devices
Joch, Thanks, apparently I had a conditional that was not matching up around that call. So now that I 'am' calling the of_platform_bus_probe(). I can see all the probe functions getting called. Thank you very much. Next question, I can see that 'quick' mods I have made to the Marvell driver are indeed matching up with the device ID that the Freescale MII device is pulling back from my 'National' part. . I.e. I can see the phy_probe get called when this Id is registered. You can see the extra debug messages above the National DP83865 device registration, and the probe returns 0 for success I assume. . I am still getting the "IP-Config: No network devices" error before the NFS boot tries to take place. BootLog: RWM DEBUG, uec_mdio_init:278 RWM DEBUG, uec_mdio_probe:145 UCC Ethernet Controller MII Bus: probed UCC Ethernet Controller MII Bus: Registered ucc_geth: QE UCC Gigabit Ethernet Controller Marvell 88E1101: Registered new driver Marvell 88E1112: Registered new driver Marvell 88E: Registered new driver RWM DEBUG: phy_probe:635 RWM DEBUG: phy_probe:663 err = 0 National DP83865: Registered new driver Marvell 88E1145: Registered new driver HDLC support module revision 1.21 usbmon: debugfs is not available mice: PS/2 mouse device common for all mice i2c /dev entries driver WDT driver for MPC83xx initialized. mode:reset timeout=65535 (16 seconds) usbcore: registered new interface driver usbhid drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 lec.c: Dec 18 2007 15:30:33 initialized mpc.c: Dec 18 2007 15:30:31 initialized IP-Config: No network devices available. NFS boot fails -Russ > -Original Message- > From: Jochen Friedrich [mailto:[EMAIL PROTECTED] > Sent: Monday, January 07, 2008 3:18 AM > To: [EMAIL PROTECTED] > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: 83xx, ucc_geth, kernel 2.6.23, IP-Config: No network devices > > Hi Russell, > > > I would appear all the appropriate entries are in the .dts file > > for each the different parts (mdio, ucc_geth, ucc_geth_mdio, phy0). > > > > And yet still no probe functions get called for any of those drivers? > > Do you export the subtree using of_platform_bus_probe()? > > Thanks, > Jochen ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
83xx, ucc_geth, kernel 2.6.23, IP-Config: No network devices
Ok, I am still stuck on this. Why isn't probe being called on any of the Freescale network device drivers? I can see the Generic MII PHY Driver being registered. The UCC_GETH and UCC_GETH_MDIO both being registered. An for fun, I even modified the Marvell PHY driver devices ID's to correctly identify a National part that I am using, and I see this registering. I would appear all the appropriate entries are in the .dts file for each the different parts (mdio, ucc_geth, ucc_geth_mdio, phy0). And yet still no probe functions get called for any of those drivers? I need this to NFS boot, into the ELDK 4.1 file system. Does anyone have an example of the 2.6.23 kernel working DTS files for a Freescale 8360 that they are using NFS Booting for? Has anyone proofed this out, or is everyone else using this as a module or driver that doesn't kick until after the root file system is loaded? Alternatively is there something specific perhaps U-boot is populating in the OF structure that is preventing my Ethernet phy from being recognized in the linux kernel? Why are none of the probe functions being called? -Russ > -Original Message- > From: Vitaly Bordug [mailto:[EMAIL PROTECTED] > Sent: Monday, December 31, 2007 12:15 AM > To: [EMAIL PROTECTED] > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: 83xx, ELDK 2.6.23, IP-Config: No network devices > > On Sun, 30 Dec 2007 16:51:44 -0800 > Russell McGuire wrote: > > > 1) Is there some basic kernel feature I am missing? I have enabled > > the GIGE UEC GETH driver in the kernel. Perhaps a PHY LIB? Isn't > > generic MII supported by default? > > > yes you will need phylib > > > 2) Is there something in the startup board files, that I need to add > > to register my PHY like an of_put_node()? Again I have pretty much > > copied the MPC8360E MDS board and it is starting, and defining the > > par_io port already, except that my PHY ID > dev ID 0x01>. However, I don't see the probe function being called, > > so I don't think this is a concern yet. > I think you will need to write a driver for your specific PHY access to > get it covered by phy abstraction layer. > Generic mii thing is useful when it has access to phy regs somehow (live > examples are some BCM phys that do not have specs > available but the thing works using generic mii and standard phy regs). ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
83xx, ELDK 2.6.23, IP-Config: No network devices
All, Attempting to get MPC8360 board booted into Linux using a NFS root fs. I can see the kernel boots up, and registers both the MDIO driver and the ucc_geth: driver, and with additional debug they encounter no errors. However, for some reason the probe function never gets called for the MDIO or the UCC driver. So as a result the IP layer never gets a network device. I am using a National DP83865 PHY device connected directly to the 83xx QE. I don't see any direct definition for this PHY device, but it doesn't even look like it queries the ID. So two questions: 1) Is there some basic kernel feature I am missing? I have enabled the GIGE UEC GETH driver in the kernel. Perhaps a PHY LIB? Isn't generic MII supported by default? 2) Is there something in the startup board files, that I need to add to register my PHY like an of_put_node()? Again I have pretty much copied the MPC8360E MDS board and it is starting, and defining the par_io port already, except that my PHY ID . However, I don't see the probe function being called, so I don't think this is a concern yet. Anyway, how do I get the UEC_driver to see my phy device so I can get the NFS to boot? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC83xx - 2.6.23, UCC_GETH and NFS Boot
All, I am attempting to get a new board booted up using NFS root file system. HW: Board based lightly on the MPC8360E_MDS I have the kernel 2.6.23-dirty configured to use the Freescale QE driver. I am using U-boot 1.3.0 and am able to use the Ethernet there, so I know it is up. I am using the following bootargs from U-boot. bootargs=console=ttyS0,115200 root=/dev/nfs rw nfsroot=192.168.5.205:/usr/local/eldk/ppc_6xx ip=192.168.5.50:192.168.5.205:192.168.5.1::MIB305_50::off I can see during initial kernel load up that it loads: "ucc_geth: QE UCC Gigabit Ethernet Controller" However, later IP-Config claims there is no valid Ethernet device registered. Is there something I have to do specify what type of PHY device I am using? Perhaps a National DP8365 is not supported yet? Or perhaps the MDIO driver in linux is not looking at the correct MDIO address? In U-boot I am using PHY addr 0x01, could this present a problem? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
DTS files, 83xx, clock frequencies
All, I note that in most of the 83xx dts config files that the different frequency fields are being populated with non-zero numbers. i.e. bus-freq, clock-freq, core-freq, etc... Isn't default behavior that these fields are kept from the U-boot during boot, if a zero is present? Is there any advantage to resetting them within the dts file during linux boot up? Or is it necessary to populate these values for correct operations, specifically with in the QUICC Engines? Over all my curiosity is that between versions of the board, i.e. different CPU's that may be clocked faster or slower, I see no reason to change the dts/blobs if I already have to change the BIOS to correctly boot up. -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
8360E - PCI - BRIDGE
I was wondering if anyone had a small suggestion of PCI cards to begin testing Linux with for debugging a PCI bus / software / setup. Basically I am looking for a couple of cards that are known to have good working PPC drivers for PCI, hopefully built-in into the kernel. Preferable that somebody has first has experience with. I seem to be having issues with Linux only, and getting my PCI stuff to work. Still not sure if these are DTV blob issues, or incompatibility with the PCI-PCI bridge chip I have in the PPC system. Questions: 1) Can somebody provide the names of just a few cards that have been tested with these 82xx 83xx PCI busses that have worked in Linux 2.6.xx? I hope to not be fighting endian issues in the drivers at first. 2) What is available / known about PCI bridge compatibility / enumeration when it comes to PPC architecture? I know Linux sees the bridge, but are there mapping compatibility issues introduced if an extra bridge is in place? 3) Directly related to Question 2, is there any special options have to be enabled in the Linux 2.6.xx kernel <2.6.20 specifically> to make this happen? PreP compliance, G5 support, no idea I am just throwing ideas. Any help appreciated, I was hoping originally that once the PCI was happy inside U-boot that Linux wouldn't be such a far target. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MPC8360 : PCI resource allocate error
I think I might be getting someplace on this debugging of the PCI slots. I solved the erratic SLOT 3 issue, it was a hardware problem. A net was unconnected, I should shoot the designer. Anyway, this was fixed that so all slots are 100% consistent. I think general issue is probably a setup problem with the PCI bridge chip. Though I do not know how U-boot and Linux set up the bridge. But after reading through the Bridge documentation, I have learned that each bus must have the memory map declared in it, for all three memory spaces. I.e. the base and the upper limit for each mem, mmio, and IO space. When I boot into Linux, with PCI cards plugged in, and I read these registers it looks as if the base address is correct, but the upper limit is actually set one byte below the base address. To me this effectively prevents all access to the memory region, halting it at the bridge chip. Would explain why the only region I can seem to read is the configuration space. I guess the question is, does Linux only enable these ranges if a card is actively using them. Or is BIOS supposed to have these enabled before the OS gets access to the bridge? > -Original Message- > From: Kumar Gala [mailto:[EMAIL PROTECTED] > Sent: Friday, February 02, 2007 8:07 AM > To: [EMAIL PROTECTED] > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: MPC8360 : PCI resource allocate error > > > On Feb 2, 2007, at 10:01 AM, Russell McGuire wrote: > > > Here is the current .dts mapping, though I am beginning to suspect the > > hardware or a possible U-boot bug on this. > > > > U-boot can't see the PCI USB card in SLOT 3, but it can see the all > > of the > > other various PCI cards I have > network card> > > Are any cards detected in SLOT 3 with u-boot? If not, I'd think HW > as well. > > > All the cards that are seen by U-boot have the IO resource problem. > > Only > > when in Slot 3. > > > > I probably need to direct this at the U-boot crowd, but what about > > these > > defines in U-boot? Would they have any bearing? I forgot to publish > > these > > when I originally had asked the question bout PCI IO space, but > > they are the > > only ALL zero's in the mapping. > > They shouldn't on just seeing the device. Since PCI config cycles > are used and U-boot will scan all busses you should at least see the > device. > > - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
radeonfb / Radeon 9250 not detecting memory
All, I seem to be hitting a fit on PCI errors on this board. Was wondering if anybody could help me through this. Here is a condensed log of what happens when I boot 2.6.20-rc6, on a MPC8360E PowerPC. I have edited out all the extra stuff and left only what should be important. The ATI card is the 1:0b:0 device that gets mapped to IRQ 0x17 I have turned on and added some extra debug in the RadeonFB driver. Is there a common place reason why the driver can't detect the memory size? Calling initcall 0xc036c3c0: pcibios_init+0x0/0x24c() PCI: Probing PCI hardware Try to map irq for :00:19.0... pci_busdev_to_OF_node(0,0xc8) parent is /[EMAIL PROTECTED]/[EMAIL PROTECTED] result is Try to map irq for :00:19.1... pci_busdev_to_OF_node(0,0xc9) parent is /[EMAIL PROTECTED]/[EMAIL PROTECTED] result is Try to map irq for :01:0b.0... pci_busdev_to_OF_node(1,0x58) pci_busdev_to_OF_node(0,0xc8) parent is /[EMAIL PROTECTED]/[EMAIL PROTECTED] result is -> got one, spec 2 cells (0x0017...) on /[EMAIL PROTECTED]/[EMAIL PROTECTED] Try to map irq for :01:0b.1... pci_busdev_to_OF_node(1,0x59) PCI: bridge rsrc 0.. (100), parent c038d184 PCI: bridge rsrc 8000..8fff (1200), parent c038d168 PCI: bridge rsrc 9000..9fff (200), parent c038d168 PCI: bridge rsrc f1001000..f1001fff (101), parent c03da03c PCI: bridge rsrc 9000..900f (200), parent c03da074 PCI: bridge rsrc 8000..8fff (1201), parent c03da058 PCI::01:0b.0: Resource 0: 8000-87ff (f=1208) PCI::01:0b.0: Resource 1: f1001000-f10010ff (f=101) PCI::01:0b.0: Resource 2: 9000-9000 (f=200) PCI::01:0b.1: Resource 0: 8800-8fff (f=1208) PCI::01:0b.1: Resource 1: 9001-9001 (f=200) Calling initcall 0xc036e440: init_qe_ic_sysfs+0x0/0x80() . Calling initcall 0xc0377300: fbmem_init+0x0/0xd0() ... Calling initcall 0xc036ee0c: mpc8360_declare_of_platform_devices+0x0/0x88() . Calling initcall 0xc0123a70: pci_init+0x0/0x50() Calling initcall 0xc037708c: pci_sysfs_init+0x0/0x58() Calling initcall 0xc03770e4: pci_proc_init+0x0/0x9c() Calling initcall 0xc03777a0: fb_console_init+0x0/0x1ac() Calling initcall 0xc037794c: radeonfb_init+0x0/0x1e0() radeonfb_pci_register BEGIN videoboot: Booting PCI video card bus 1, function 0, device 11 RWM rinfo->name[] ATI Radeon Y` RWM rinfo->family 000a RWM rinfo->chipset 5960 RWM rinfo->fb_base_phys 8000 RWM rinfo->mmio_base_phys 9000 RWM rinfo->mmio_base d1058000 VENDOR_ID 0f00 = 59601002 DEVICE_ID 0f02 = 00075960 CONFIG_MEMSIZE 00f8 = REG_MEM_BASE 0f10 = 8008 pci_busdev_to_OF_node(1,0x58) radeonfb (:01:0b.0): Cannot match card to OF node ! aper_base: 8000 MC_FB_LOC to: 87ff8000, MC_AGP_LOC to: 9000 RWM VideoRAM size read radeonfb (:01:0b.0): Found 0k of SDRAM 64 bits wide videoram radeonfb (:01:0b.0): cannot map FB radeonfb: probe of :01:0b.0 failed with error -5 -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: 8360E - PCI / DTC Blob Setup
> On Feb 2, 2007, at 7:36 AM, Russell McGuire wrote: > > > > > Well I am getting smarter on this: > > > > I have read through the PCI Bridge Specs and found another issue > > that might > > have been causing a problem with the IDSEL lines. Unless you are > > interested > > I'll forgo that explanation and just go with fact that I have > > changed the > > IDSEL mappings to be legal when they are issued from the 83xx. > > > > I have changed the IDSELs to be as follows, does this look correct? > > Not sure, I'm a little confused as to how exactly things are wired on > your board. It would seem like you have 2 P2P bridges connected to > the processor. Behind one bridge is 2 slots and behind the second is > 1 slot? Absolutely correct, I probably should send a picture. :-) But yes, the CPU host bridge is directly connected to a DUAL P2P bridge chip. There are no SLOTS on BUS 0. The P2P then provides BUS 1 and BUS 2. I did this in the design to allow slower 33Mhz cards to operate in the system without slowing down the 66Mhz cards . BUS 1 has two slots, and BUS 2 has one slot, for a total of three. I would be more than happy to send a 2 page PDF file of the schematic. This design obviously hasn't been proofed yet. Though it 'seems' to almost work. -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MPC8360 : PCI resource allocate error
Comments in line: > On Feb 2, 2007, at 10:01 AM, Russell McGuire wrote: > > > Here is the current .dts mapping, though I am beginning to suspect the > > hardware or a possible U-boot bug on this. > > > > U-boot can't see the PCI USB card in SLOT 3, but it can see the all > > of the > > other various PCI cards I have > network card> > > Are any cards detected in SLOT 3 with u-boot? If not, I'd think HW > as well. Yes, actually of the 6 cards I have, all are seen except the USB card. And the USB card is seen in all other slots. So it appears to be a SLOT issue, but not a card issue. Somehow this card is unique and uncovering an error that I don't know about yet. Perhaps I have a single address line sizzled or something. This is the same slot that has the IO resource allocation problems; I don't think I need to debug that in Linux. OR.. Is there any PCI test code out there??? Maybe I should forego the drivers, and figure out some kind of test. I made a blind assumption in U-boot that if it worked to detect cards that everything was in order. > > > All the cards that are seen by U-boot have the IO resource problem. > > Only > > when in Slot 3. > > > > I probably need to direct this at the U-boot crowd, but what about > > these > > defines in U-boot? Would they have any bearing? I forgot to publish > > these > > when I originally had asked the question bout PCI IO space, but > > they are the > > only ALL zero's in the mapping. > > They shouldn't on just seeing the device. Since PCI config cycles > are used and U-boot will scan all busses you should at least see the > device. > > - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MPC8360 : PCI resource allocate error
Here is the current .dts mapping, though I am beginning to suspect the
hardware or a possible U-boot bug on this.
U-boot can't see the PCI USB card in SLOT 3, but it can see the all of the
other various PCI cards I have
All the cards that are seen by U-boot have the IO resource problem. Only
when in Slot 3.
I probably need to direct this at the U-boot crowd, but what about these
defines in U-boot? Would they have any bearing? I forgot to publish these
when I originally had asked the question bout PCI IO space, but they are the
only ALL zero's in the mapping.
-STUFF I FORGET TO PUBLISH ---
#define CFG_PCI_SLV_MEM_LOCAL CFG_SDRAM_BASE //= 0x_
#define CFG_PCI_SLV_MEM_BUS 0x
#define CFG_PCI_SLV_MEM_SIZE0x8000 //Should this be 2GB
--
OTHER U-BOOT DEFINES
#define CFG_PCI_MEM_BASE0x8000
#define CFG_PCI_MEM_PHYSCFG_PCI_MEM_BASE
#define CFG_PCI_MEM_SIZE0x1000 /* 256M */
#define CFG_PCI_MMIO_BASE 0x9000
#define CFG_PCI_MMIO_PHYS CFG_PCI_MMIO_BASE
#define CFG_PCI_MMIO_SIZE 0x1000 /* 256M */
#define CFG_PCI_IO_BASE 0xF030
#define CFG_PCI_IO_PHYS 0xF030
#define CFG_PCI_IO_SIZE 0x0010 /* 1M */
--
Here is the dts section
-
[EMAIL PROTECTED] {
linux,phandle = <8500>;
interrupt-map-mask = <3f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x19 AD25 */
c800 0 0 1 700 14 8
c800 0 0 2 700 15 8
c800 0 0 3 700 16 8
c800 0 0 4 700 17 8
/* IDSEL 0x1B AD27 */
15800 0 0 1 700 14 8
15800 0 0 2 700 15 8
15800 0 0 3 700 16 8
15800 0 0 4 700 17 8
/* IDSEL 0x1E AD30*/
17000 0 0 1 700 14 8
17000 0 0 2 700 15 8
17000 0 0 3 700 16 8
17000 0 0 4 700 17 8
/* IDSEL 0x1B AD27 */
25800 0 0 1 700 14 8
25800 0 0 2 700 15 8
25800 0 0 3 700 16 8
25800 0 0 4 700 17 8
>;
interrupt-parent = <700>;
interrupts = <42 8>;
bus-range = <0 0>;
ranges = <4200 0 8000 8000 0 1000
0200 0 9000 9000 0 1000
0100 0 f030 f030 0 0010>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
compatible = "83xx";
device_type = "pci";
};
-- END DTS --
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Friday, February 02, 2007 7:28 AM
To: [EMAIL PROTECTED]
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC8360 : PCI resource allocate error
On Feb 2, 2007, at 9:04 AM, Russell McGuire wrote:
> While trying out various of my PCI slots, I ran into this
> interesting error.
>
>
>
> If I try to put a sounc card, Audigy SE, into SLOT 1 and 2 this
> error doesn't occur.
>
> But when I place it in the 3rd. I get this: SLOT 3>
>
>
>
>
>
>
>
> --
>
> PCI: Probing PCI hardware
>
> Try to map irq for :00:19.0...
>
> pci_busdev_to_OF_node(0,0xc8)
>
> parent is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
>
> result is
>
> Try to map irq for :00:19.1...
>
> pci_busdev_to_OF_node(0,0xc9)
>
> parent is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
>
> result is
>
> Try to map irq for :02:0b.0...
>
> pci_busdev_to_OF_node(2,0x58)
>
> pci_busdev_to_OF_node(0,0xc9)
>
> parent is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
>
> result is
>
> -> got one, spec 2 cells (0x0017...) on /[EMAIL PROTECTED]/[EMAIL
> PROTECTED]
>
> PCI: bridge rsrc 0.. (100), parent c038d184
>
> PCI: bridge rsrc 8000..8fff (1200), parent c038d168
>
> PCI: bridge rsrc 9000..9fff (200), parent c038d168
>
> PCI: bridge rsrc f0302000..f0302fff (101), parent c03da03c
>
> PCI::02:0b.0: Resource 0: 00302000-0030201f
> (f=101)
>
> PCI: Cannot allocate resource regi
MPC8360 : PCI resource allocate error
While trying out various of my PCI slots, I ran into this interesting error. If I try to put a sounc card, Audigy SE, into SLOT 1 and 2 this error doesn't occur. But when I place it in the 3rd. I get this: -- PCI: Probing PCI hardware Try to map irq for :00:19.0... pci_busdev_to_OF_node(0,0xc8) parent is /[EMAIL PROTECTED]/[EMAIL PROTECTED] result is Try to map irq for :00:19.1... pci_busdev_to_OF_node(0,0xc9) parent is /[EMAIL PROTECTED]/[EMAIL PROTECTED] result is Try to map irq for :02:0b.0... pci_busdev_to_OF_node(2,0x58) pci_busdev_to_OF_node(0,0xc9) parent is /[EMAIL PROTECTED]/[EMAIL PROTECTED] result is -> got one, spec 2 cells (0x0017...) on /[EMAIL PROTECTED]/[EMAIL PROTECTED] PCI: bridge rsrc 0.. (100), parent c038d184 PCI: bridge rsrc 8000..8fff (1200), parent c038d168 PCI: bridge rsrc 9000..9fff (200), parent c038d168 PCI: bridge rsrc f0302000..f0302fff (101), parent c03da03c PCI::02:0b.0: Resource 0: 00302000-0030201f (f=101) PCI: Cannot allocate resource region 0 of device :02:0b.0 PCI: Error while updating region :02:0b.0/0 (f0302001 != 00302001) -- What can cause this to not work? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: 8360E - PCI / DTC Blob Setup
Well I am getting smarter on this: I have read through the PCI Bridge Specs and found another issue that might have been causing a problem with the IDSEL lines. Unless you are interested I'll forgo that explanation and just go with fact that I have changed the IDSEL mappings to be legal when they are issued from the 83xx. I have changed the IDSELs to be as follows, does this look correct? I agree with placing the NODE for the bridge into the dts file to be correct. Except I get stuck immediately at trying to come up with an address. I.e. the PCI host has a [EMAIL PROTECTED], which makes sense. But the Bridge chip doesn't have a mapped address to place in the file. I did read the PCI OF node spec it hints that PCI-PCI bridges are essentially the same domain and may not need translation. Another concern I have now is that the interrupt mask may be incorrect. i.e. currently it is , should I change this to <3f800 0 0 7> since I am using an extra 2 bits to indicate bus? This would make sense if the ((Bus << 16) | Dev << 11)) >> Bus 1, Slot 1, (Bridge IDSEL = AD27 mapped to IDSEL AD11 on host) > 15800 0 0 1 700 14 8 //Int A always to IRQ 20 > 15800 0 0 2 700 15 8 //Int B always to IRQ 21 > 15800 0 0 3 700 16 8 //Int C always to IRQ 22 > 15800 0 0 4 700 17 8 //Int D always to IRQ 23 >> Bus 1, Slot 2, (Bridge IDSEL = AD30 mapped to IDSEL AD13 on host) > 17000 0 0 1 700 14 8 > 17000 0 0 2 700 15 8 > 17000 0 0 3 700 16 8 > 17000 0 0 4 700 17 8 >> Bus 2, Slot 1, (Bridge IDSEL = AD27 mapped to IDSEL AD11 on host) > 25800 0 0 1 700 14 8 > 25800 0 0 2 700 15 8 > 25800 0 0 3 700 16 8 > 25800 0 0 4 700 17 8 These IDSEL mappings seem to match exactly what U-boot will report i.e. Bus.Dev = 1.0b, 1.0e, 2.0b. I have not placed any reference to the Bridge chip's IDSEL line, since it cannot activate any IRQ lines directly. Well try it both ways perhaps and see what happens. The good news is with this configuration, the ca0106 driver will load. I can get all the way into linux, and see the associated creations under the /proc/ file system. To me all this really proves to me is that the IRQ hasn't been toggled. Now I have to figure out how to get the /dev/dsp devices in the /dev directory. If ALSA still uses this, I am used to OSS. I am trying a PCI USB 2.0 card now, with various drivers and devices plugged in I get varying results from 'try irqpoll' to boot hanging. Not sure if this is an IRQ problem or a another related PCI bug. What fun this is. -Russ -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Thursday, February 01, 2007 10:21 PM To: [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org E-Mail; Benjamin Herrenschmidt Subject: Re: 8360E - PCI / DTC Blob Setup On Feb 1, 2007, at 8:49 PM, Russell McGuire wrote: > Kumar, > > THANK you, for pointing me in the right direction. I might have > scratched my > head another 10 years finding this bug. And an apology for thinking > I had a > software issue, when it was a hardware issue. No problem, this pretty much comes out of the PCI OF spec, but it takes a while to grok how we actually use it. > This is helping me greatly, all the while I had this sinking > feeling, like I > didn't route any 'incoming' interrupt lines to the CPU. Something > about the > 8360 being able to get configured as an agent device, so I over > looked the > use of the INTA pin on the CPU as incoming vs outgoing. > > SO it would seem I didn't have ANY incoming pins, and thus the > IRQ4-7 pins > that occur in the 8360E-MDS board were floating on my board. So as > soon as > the sound driver enabled the interrupt, it was low all the time. That would definitely be a HW issue :) >> (on 83xx):> >> >> [linux,phandle for interrupt controller] [IRQ #] [sense] > > I assume all these numbers are in HEX, So 0x14, 0x 15, 0x 16, 0x 17 > would > correspond to external IRQ4-7 in the MPC8360E. I will wire this up > and give > it a shot, guess it works better when they are connected. Yeah all numbers are hex, I forget if you can put a leading 0x or not.. its kinda annoying. >> : >> >> [(bus << 16) | (idsel << 11)] 0 0 > > Well I think this is definitely part of my problem. > So I am mapping interrupts from bus 1 and 2, I would need something > like? Truthfully you should probably have child nodes that describe the bridges and have their interrupt mappings described there. The code is going to end up using the Bus #, IDSEL for the pci device to try and determine the CPU ext interrupt its mapped to. Unfortunately, we don't really have an example of this. > Alternating the 14,15,16,17 to make a 'load-balanced' mapping? Are > the bus not following the quest
RE: 8360E - PCI / DTC Blob Setup
Kumar, THANK you, for pointing me in the right direction. I might have scratched my head another 10 years finding this bug. And an apology for thinking I had a software issue, when it was a hardware issue. This is helping me greatly, all the while I had this sinking feeling, like I didn't route any 'incoming' interrupt lines to the CPU. Something about the 8360 being able to get configured as an agent device, so I over looked the use of the INTA pin on the CPU as incoming vs outgoing. SO it would seem I didn't have ANY incoming pins, and thus the IRQ4-7 pins that occur in the 8360E-MDS board were floating on my board. So as soon as the sound driver enabled the interrupt, it was low all the time. > (on 83xx):> > >[linux,phandle for interrupt controller] [IRQ #] [sense] I assume all these numbers are in HEX, So 0x14, 0x 15, 0x 16, 0x 17 would correspond to external IRQ4-7 in the MPC8360E. I will wire this up and give it a shot, guess it works better when they are connected. >: > >[(bus << 16) | (idsel << 11)] 0 0 Well I think this is definitely part of my problem. So I am mapping interrupts from bus 1 and 2, I would need something like? Alternating the 14,15,16,17 to make a 'load-balanced' mapping? Are the bus > Bus 1, Slot 1, IDSEL = AD20 1a000 0 0 1 700 14 8 1a000 0 0 1 700 15 8 1a000 0 0 1 700 16 8 1a000 0 0 1 700 17 8 > Bus 1, Slot 2, IDSEL = AD24 1c000 0 0 1 700 15 8 1c000 0 0 1 700 16 8 1c000 0 0 1 700 17 8 1c000 0 0 1 700 18 8 > Bus 2, Slot 1, IDSEL = AD20 2a000 0 0 1 700 16 8 2a000 0 0 1 700 17 8 2a000 0 0 1 700 18 8 2a000 0 0 1 700 19 8 -Russ -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Thursday, February 01, 2007 10:11 AM To: [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org Subject: Re: 8360E - PCI / DTC Blob Setup On Feb 1, 2007, at 11:48 AM, Russell McGuire wrote: > This might be the wrong forum to discuss HW routing, but I am not > sure of > many HW guys that would understand blob setups. I know I still don't. > > I read through the booting-without-of-tree.txt and it doesn't > explain this > other than the interrupt routing needs to be present. Perhaps some > of the > maintainers of the 83xx platforms can explain how this blob is > developed? > I assume their board work with the submitted mp38360emds.dts files, > as an > example. > > Let me see if I can simplify this, I had this schematic reviewed by > Pericom > and they recommended these IDSEL lines. And I > know the > card detection works great, in U-boot. > > My external PCI bridge is the only thing routed directly to the > 8360 Host > bridge. The PCI Host bridge in my system is connected on IDSEL- > >AD25,0x19 > Perhaps I shouldn't use any interrupt routing for this, as there is > no true > /INTA line tied directly to the bridge? > > My Three PCI slots are routed as follows: > > Bus 0, Bridge Chip, IDSEL = AD25 Huh, this is only describes one slot/connection. If you have 3 slots, they'd have 3 unique IDSELs > Other side of the Host bridge, all are routed to INTA directly to the > CPU. > Bus 1, Slot 1, IDSEL = AD20 > Bus 1, Slot 2, IDSEL = AD24 > Bus 2, Slot 1, IDSEL = AD20 > > That being said: > /* IDSEL 0x19 AD25*/ > c800 0 0 1 700 14 8 so the way you read this: Do break it down further: : [(bus << 16) | (idsel << 11)] 0 0 : INTA - 1 INTB - 2 INTC - 3 INTD - 4 (on 83xx): [linux,phandle for interrupt controller] [IRQ #] [sense] > I see in the c800 directly corresponds to the 83xx manual for PCI > CONFIG > address mapping for AD25. > > I think the '1' is mapped to /INTA, which is the only PCI INT > available in > the 8360E. INTA..INTD is more about the device, not host. > I understand the 700 in this case is the address of the [EMAIL PROTECTED] > > That leaves 5 fields/questions. > 1) What do the first two '0's after c800 mean? There always 0 0, since the int masks them away (they normally describe the address the device is at) > 2) What does the '14' map to? 0x14 is the external IRQ # its wired to. > 3) What does the '8' map to? Sense of IRQ, should always be level for PCI. > 4) Why would some boards map multiple interrupts to a single IDSEL, > like the > mpc8360emds.dts file? Is this to handle extra bridges that might be > plugged > in at a later time? This is to handle the fact that a PCI add on card put into a slot might use multiple interrupts (INTA, INTB), so it lists multiple entries to cover the 4 PCI defined interrupts. > If I understand the mapping correctly then I think I can hard code > in the > interrupts for the PCI slots. > > So I don't drive everybody nuts, is there
RE: 8360E - PCI / DTC Blob Setup
This might be the wrong forum to discuss HW routing, but I am not sure of many HW guys that would understand blob setups. I know I still don't. I read through the booting-without-of-tree.txt and it doesn't explain this other than the interrupt routing needs to be present. Perhaps some of the maintainers of the 83xx platforms can explain how this blob is developed? I assume their board work with the submitted mp38360emds.dts files, as an example. Let me see if I can simplify this, I had this schematic reviewed by Pericom and they recommended these IDSEL lines. And I know the card detection works great, in U-boot. My external PCI bridge is the only thing routed directly to the 8360 Host bridge. The PCI Host bridge in my system is connected on IDSEL->AD25,0x19 Perhaps I shouldn't use any interrupt routing for this, as there is no true /INTA line tied directly to the bridge? My Three PCI slots are routed as follows: Bus 0, Bridge Chip, IDSEL = AD25 Other side of the Host bridge, all are routed to INTA directly to the CPU. Bus 1, Slot 1, IDSEL = AD20 Bus 1, Slot 2, IDSEL = AD24 Bus 2, Slot 1, IDSEL = AD20 That being said: /* IDSEL 0x19 AD25*/ c800 0 0 1 700 14 8 I see in the c800 directly corresponds to the 83xx manual for PCI CONFIG address mapping for AD25. I think the '1' is mapped to /INTA, which is the only PCI INT available in the 8360E. I understand the 700 in this case is the address of the [EMAIL PROTECTED] That leaves 5 fields/questions. 1) What do the first two '0's after c800 mean? 2) What does the '14' map to? 3) What does the '8' map to? 4) Why would some boards map multiple interrupts to a single IDSEL, like the mpc8360emds.dts file? Is this to handle extra bridges that might be plugged in at a later time? If I understand the mapping correctly then I think I can hard code in the interrupts for the PCI slots. So I don't drive everybody nuts, is there actual documentation on this. I would be happy to stop spamming this list... :-) -Russ -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Thursday, February 01, 2007 6:33 AM To: [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org Subject: Re: 8360E - PCI / DTC Blob Setup On Feb 1, 2007, at 8:27 AM, Russell McGuire wrote: > Since I am hip deep in debugging the PCI system. > > In the .dts files there is the section for the PCI setup. > > The interrupt-map = < > > > Does this need to include: > 1) A mapping for every IDSEL line in the system? > 2) Only those IDSELs that are used on the slots on the motherboard? I'm not sure I follow the difference between 1/2. The map needs to cover every IDSEL that has an IRQ line wired to it. > 3) A custom entry for every card we want to support? See above. > 4) How does a bridge chip and slave busses affect the entries, if > at all? Uugh, I'm not sure how bridges are handled at this point. > Looking at the mpc8360 / 8349 setups that are part of the latest > kernel > trees, some are place many and some are placing just a single entry? > > Which should be the preferred method? It depends on your HW setup, the 8360/49 boards have some 'odd' IDSEL irq mapping. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
8360E - PCI / DTC Blob Setup
Since I am hip deep in debugging the PCI system. In the .dts files there is the section for the PCI setup. The interrupt-map = < > Does this need to include: 1) A mapping for every IDSEL line in the system? 2) Only those IDSELs that are used on the slots on the motherboard? 3) A custom entry for every card we want to support? 4) How does a bridge chip and slave busses affect the entries, if at all? Looking at the mpc8360 / 8349 setups that are part of the latest kernel trees, some are place many and some are placing just a single entry? Which should be the preferred method? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Audigy SE / ca0106 driver for PowerPC?
All, Well I figured out part of the problem, maybe we can figure out why this was causing an issue?? On a hunch I changed the U-boot and Blob files, to be different on one of the addresses for the PCI IO space. -OLD- #define CFG_PCI_IO_BASE 0x #define CFG_PCI_IO_PHYS 0xF030 #define CFG_PCI_IO_SIZE 0x0010 /* 1M */ -NEW- #define CFG_PCI_IO_BASE 0xF030 <--- CHANGED THIS #define CFG_PCI_IO_PHYS 0xF030 #define CFG_PCI_IO_SIZE 0x0010 /* 1M */ The system no longer locks up now, so it looks like the bus hang is fixed. However, now the sound driver never exits the interrupt routine. So I have to figure out why I am getting continuous interrupts. -Russ -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 4:04 PM To: [EMAIL PROTECTED] Subject: Re: Audigy SE / ca0106 driver for PowerPC? On Jan 31, 2007, at 5:47 PM, Russell McGuire wrote: > > When Linux loads are there left over memory mappings in the PCI > from U-boot, > Or does the PCI initializing in Linux reset these values, and just > place in > what the BLOB contains? Linux doesn't override the PCILAW* settings, it expects that the physical memory map is setup by the bootloader. > I guess is it critical that the BLOB 100% match the U-boot > definitions, > other than it being confusing to developers? Yeah, I think about making it smarter. The problem is being smart about it... For example in your setup, its uses one LAW to cover both PCI mem regions. - k > -Original Message- > From: Kumar Gala [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 31, 2007 2:40 PM > To: [EMAIL PROTECTED] > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: Audigy SE / ca0106 driver for PowerPC? > > > On Jan 31, 2007, at 4:27 PM, Russell McGuire wrote: > >> This makes sense... >> >> So if I have setup in U-boot the PCI IO space to be at 0xf030 >> and PCI >> MOM space at 0x8000 then the inl() command should be accessing >> the >> 0xf030 space? And the frame buffer is accessing the 0x8000. > > That's correct, however both of these will go through ioremap to get > virtual addresses in the kernel. For the IO space its done in the > PCI setup code for the platform, and for MEM space its done by the > driver. > >> The lock I experience, is when I compile the driver into the >> kernel. During >> the PCI Probing, I have turned on ALL of the debug output, as well >> as placed >> a ton of extra debug inside the ca0106 driver. I can see >> clearly >> the kernel detects I have a sound card, as does it detect the video >> card. >> Though I haven't gotten any PCI cards to function yet... The machine >> literally just halts the boot cycle inside the first inl() command, >> and just >> sits here until the reset button is pressed. It feels much like an >> illegal >> access to a non-existant memory space > = bus >> hang?> > > Ah, this we can debug :) > > In arch/powerpc/kernel/pci_32.c enable DEBUG in the file (change the > #undef DEBUG to #define DEBUG). At which you'll get some output of > the form. > > Also, you can stick a few printk's in pci_process_bridge_OF_ranges > (). I'd suggest one before: > > hose->io_base_virt = ioremap(ranges[na+2], size); > >> Perhaps then my problem lies in the OF_BLOB I am passing in to >> Linux? Could >> this cause the problem? Is there a document someplace that >> describes the >> passed into the kernel on the OF_BLOB for the PCI >> setup? I >> made a good guess estimating this from other BLOB/dts files, but >> it is >> possible I have some incorrect values. > > That would cause problems if not setup correctly. Look at > Documentation/powerpc/booting-without-of.txt, however a quick glance > doesn't seem to cover PCI. > > You've given the start addresses for PCI MEM & PCI IO, can you tell > me the sizes and I can help tell you want the node should look like. > > - k > >> -Original Message- >> From: Kumar Gala [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, January 31, 2007 1:55 PM >> To: [EMAIL PROTECTED] >> Cc: linuxppc-embedded@ozlabs.org >> Subject: Re: Audigy SE / ca0106 driver for PowerPC? >> >> >> On Jan 31, 2007, at 3:00 PM, Russell McGuire wrote: >> >>> I am using the Freescale MPC8360E, with U-boot 1.2.0. >>> When I compile the kernel <2.6.20-rc6> I select the MPC8360E-MDS >>> board. >>> ARCH = PowerPC. >>> >>> Well I might be all confused on the IO
RE: Audigy SE / ca0106 driver for PowerPC?
/* Configure PCI Local Access Windows */
pci_law[0].bar = CFG_PCI_MEM_PHYS & LAWBAR_BAR;
pci_law[0].ar = LAWAR_EN | LAWAR_SIZE_512M;
pci_law[1].bar = CFG_PCI_IO_PHYS & LAWBAR_BAR;
pci_law[1].ar = LAWAR_EN | LAWAR_SIZE_1M;
-Russ
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 31, 2007 3:19 PM
To: [EMAIL PROTECTED]
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Audigy SE / ca0106 driver for PowerPC?
On Jan 31, 2007, at 5:01 PM, Russell McGuire wrote:
>
> What I really don't know is what the first column in the ranges
> field does.
> I.e. the <4200>, <0200>, and <0100>.
They are encoding of type of "space" is being described, the first
byte's what's important:
[42]- prefetchable memory
[02]- 32-bit memory space
[01]- IO space
[00]- CFG space
[03]- 64-bit memory space
> Here is part of current blob I am using:
>
> [EMAIL PROTECTED] {
> linux,phandle = <8500>;
> interrupt-map-mask = ;
> interrupt-map= <
> /* IDSEL 0x19 AD25*/
>c800 0 0 1 700 14 8
>c800 0 0 2 700 15 8
>c800 0 0 3 700 16 8
>c800 0 0 4 700 17 8>; > //and a lot more like this
> bus-range = <0 0>; //U-boot modifies this to be <0 2> I think
> ranges = <4200 0 8000 8000 0 1000
> 0200 0 9000 9000 0 1000
> 0100 0 f030 0 0010>;
> clock-frequency = <3f940aa>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <8500 100>;
> compatible = "83xx";
> device_type = "pci";
> }
>
> Here are the U-boot #defines I am using at the moment.
>
> #define CFG_PCI_MEM_BASE 0x8000
> #define CFG_PCI_MEM_PHYS CFG_PCI_MEM_BASE
> #define CFG_PCI_MEM_SIZE 0x1000 /* 256M */
> #define CFG_PCI_MMIO_BASE 0x9000
> #define CFG_PCI_MMIO_PHYS CFG_PCI_MMIO_BASE
> #define CFG_PCI_MMIO_SIZE 0x1000 /* 256M */
> #define CFG_PCI_IO_BASE 0x
> #define CFG_PCI_IO_PHYS 0xF030
> #define CFG_PCI_IO_SIZE 0x0010 /* 1M */
> Might need to change PCI_IO_BASE to match PCI_IO_PHYS as well?
This all looks correct, how are you setting PCILAWBAR0/1, PCILAWAR0/1?
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Audigy SE / ca0106 driver for PowerPC?
What I really don't know is what the first column in the ranges field does.
I.e. the <4200>, <0200>, and <0100>.
Here is part of current blob I am using:
[EMAIL PROTECTED] {
linux,phandle = <8500>;
interrupt-map-mask = ;
interrupt-map= <
/* IDSEL 0x19 AD25*/
c800 0 0 1 700 14 8
c800 0 0 2 700 15 8
c800 0 0 3 700 16 8
c800 0 0 4 700 17 8>; > //and a lot more like this
bus-range = <0 0>; //U-boot modifies this to be <0 2> I think
ranges = <4200 0 8000 8000 0 1000
0200 0 9000 9000 0 1000
0100 0 f030 0 0010>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
compatible = "83xx";
device_type = "pci";
}
Here are the U-boot #defines I am using at the moment.
#define CFG_PCI_MEM_BASE0x8000
#define CFG_PCI_MEM_PHYSCFG_PCI_MEM_BASE
#define CFG_PCI_MEM_SIZE0x1000 /* 256M */
#define CFG_PCI_MMIO_BASE 0x9000
#define CFG_PCI_MMIO_PHYS CFG_PCI_MMIO_BASE
#define CFG_PCI_MMIO_SIZE 0x1000 /* 256M */
#define CFG_PCI_IO_BASE 0x
#define CFG_PCI_IO_PHYS 0xF030
#define CFG_PCI_IO_SIZE 0x0010 /* 1M */
Might need to change PCI_IO_BASE to match PCI_IO_PHYS as well?
-Russ
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 31, 2007 2:40 PM
To: [EMAIL PROTECTED]
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Audigy SE / ca0106 driver for PowerPC?
On Jan 31, 2007, at 4:27 PM, Russell McGuire wrote:
> This makes sense...
>
> So if I have setup in U-boot the PCI IO space to be at 0xf030
> and PCI
> MOM space at 0x8000 then the inl() command should be accessing the
> 0xf030 space? And the frame buffer is accessing the 0x8000.
That's correct, however both of these will go through ioremap to get
virtual addresses in the kernel. For the IO space its done in the
PCI setup code for the platform, and for MEM space its done by the
driver.
> The lock I experience, is when I compile the driver into the
> kernel. During
> the PCI Probing, I have turned on ALL of the debug output, as well
> as placed
> a ton of extra debug inside the ca0106 driver. I can see
> clearly
> the kernel detects I have a sound card, as does it detect the video
> card.
> Though I haven't gotten any PCI cards to function yet... The machine
> literally just halts the boot cycle inside the first inl() command,
> and just
> sits here until the reset button is pressed. It feels much like an
> illegal
> access to a non-existant memory space = bus
> hang?>
Ah, this we can debug :)
In arch/powerpc/kernel/pci_32.c enable DEBUG in the file (change the
#undef DEBUG to #define DEBUG). At which you'll get some output of
the form.
Also, you can stick a few printk's in pci_process_bridge_OF_ranges
(). I'd suggest one before:
hose->io_base_virt = ioremap(ranges[na+2], size);
> Perhaps then my problem lies in the OF_BLOB I am passing in to
> Linux? Could
> this cause the problem? Is there a document someplace that
> describes the
> passed into the kernel on the OF_BLOB for the PCI
> setup? I
> made a good guess estimating this from other BLOB/dts files, but it is
> possible I have some incorrect values.
That would cause problems if not setup correctly. Look at
Documentation/powerpc/booting-without-of.txt, however a quick glance
doesn't seem to cover PCI.
You've given the start addresses for PCI MEM & PCI IO, can you tell
me the sizes and I can help tell you want the node should look like.
- k
> -Original Message-----
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 31, 2007 1:55 PM
> To: [EMAIL PROTECTED]
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Audigy SE / ca0106 driver for PowerPC?
>
>
> On Jan 31, 2007, at 3:00 PM, Russell McGuire wrote:
>
>> I am using the Freescale MPC8360E, with U-boot 1.2.0.
>> When I compile the kernel <2.6.20-rc6> I select the MPC8360E-MDS
>> board.
>> ARCH = PowerPC.
>>
>> Well I might be all confused on the IO Remap, but if I look through
>> the
>> nvidafb driver and the ati frame buffer driver I can see the
>> resource_start() and pci_resource_len() function being called,
>> followed by
>> the ioremap() before any configuration is done with the PCI boards.
>
> The difference is the nvidafb driver isn't doing PCI
RE: Audigy SE / ca0106 driver for PowerPC?
This makes sense... So if I have setup in U-boot the PCI IO space to be at 0xf030 and PCI MOM space at 0x8000 then the inl() command should be accessing the 0xf030 space? And the frame buffer is accessing the 0x8000. The lock I experience, is when I compile the driver into the kernel. During the PCI Probing, I have turned on ALL of the debug output, as well as placed a ton of extra debug inside the ca0106 driver. I can see clearly the kernel detects I have a sound card, as does it detect the video card. Though I haven't gotten any PCI cards to function yet... The machine literally just halts the boot cycle inside the first inl() command, and just sits here until the reset button is pressed. It feels much like an illegal access to a non-existant memory space Perhaps then my problem lies in the OF_BLOB I am passing in to Linux? Could this cause the problem? Is there a document someplace that describes the passed into the kernel on the OF_BLOB for the PCI setup? I made a good guess estimating this from other BLOB/dts files, but it is possible I have some incorrect values. -Russ -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 1:55 PM To: [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org Subject: Re: Audigy SE / ca0106 driver for PowerPC? On Jan 31, 2007, at 3:00 PM, Russell McGuire wrote: > I am using the Freescale MPC8360E, with U-boot 1.2.0. > When I compile the kernel <2.6.20-rc6> I select the MPC8360E-MDS > board. > ARCH = PowerPC. > > Well I might be all confused on the IO Remap, but if I look through > the > nvidafb driver and the ati frame buffer driver I can see the > resource_start() and pci_resource_len() function being called, > followed by > the ioremap() before any configuration is done with the PCI boards. The difference is the nvidafb driver isn't doing PCI IO but PCI mem accesses (note, I didn't see any inl/outl references in the nvida driver). > The ca0106 driver seems to miss this function, and it is > the only > one that 100% locks the system up during the PCI probing tried>, and it happens after/during the very first inl() or outl() > command. This may be because IO space is setup properly. When you say locks the system, what exactly happens? > I read a thread someplace that says that pci_resource_start() is not > intended to return an actual address, but rather a token that is to > be used > by the ioremap() function? It just happens that on some systems > this value > is the same and so for some it will not fail with a missing ioremap > (), but > others it will not be. To be safe it must be passed through ioremap > ()? This > is the deprecated part, a better > one> that this driver makes. > > After looking through more drivers, this ioremap seems 100% in > place on my > drivers. Maybe nobody has tested this with PowerPC in the past? ioremap() is intended for use with PCI MEM accesses not PCI IO. If you think about the fact that PCI IO is based on the x86 port IO concept this makes sense. > See this thread as an example: > http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/1187.html > > Or see: > /drivers/video/nvidia/nvidia.c lines 1239->1243 > > Verses > > /sound/pci/ca0106/ca0106_main.c > lines 1279 till the interrupt request > then lines 1069->1089 at which it locks on inl() > > I don't mean to argue, I am just confused at this point. Its ok. I don't thinking you're arguing, just trying to figure out what's going on. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Audigy SE / ca0106 driver for PowerPC?
I am using the Freescale MPC8360E, with U-boot 1.2.0. When I compile the kernel <2.6.20-rc6> I select the MPC8360E-MDS board. ARCH = PowerPC. Well I might be all confused on the IO Remap, but if I look through the nvidafb driver and the ati frame buffer driver I can see the resource_start() and pci_resource_len() function being called, followed by the ioremap() before any configuration is done with the PCI boards. The ca0106 driver seems to miss this function, and it is the only one that 100% locks the system up during the PCI probing , and it happens after/during the very first inl() or outl() command. I read a thread someplace that says that pci_resource_start() is not intended to return an actual address, but rather a token that is to be used by the ioremap() function? It just happens that on some systems this value is the same and so for some it will not fail with a missing ioremap(), but others it will not be. To be safe it must be passed through ioremap()? This is the deprecated part, that this driver makes. After looking through more drivers, this ioremap seems 100% in place on my drivers. Maybe nobody has tested this with PowerPC in the past? See this thread as an example: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/1187.html Or see: /drivers/video/nvidia/nvidia.c lines 1239->1243 Verses /sound/pci/ca0106/ca0106_main.c lines 1279 till the interrupt request then lines 1069->1089 at which it locks on inl() I don't mean to argue, I am just confused at this point. -Russ -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 7:34 AM To: [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org Subject: Re: Audigy SE / ca0106 driver for PowerPC? On Jan 31, 2007, at 9:20 AM, Russell McGuire wrote: > After comparing the driver methods to a couple of other PCI drivers > that do > work on PowerPC , it looks like the > methods > for accessing the PCI IO space are very depreciated in this driver.. Not sure I follow that comment, in*/out* have been the mechanisms to access PCI IO space for as long as I've know. > Would it be safe to assume that if I were to modify the existing > > chip->port = pci_resource_start(pcidev,0); > chip->res_port = request_region(chip->port, size); > > outl(chip->port+MyReg, data); > > To something like: > > chip->port = pci_resource_start(pcidev,0); > snd_length = pci_resource_len(pcidev, 0); > snd_port = ioremap(chip->port, length); > > outl(port+MyReg, data); > > I am not sure if I want to leave the outl in there, perhaps a > different > function, or just a direct assignment? You shouldn't have to do the ioremap, the PCI platform code should have already handled all of this. What PPC platform are you on? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Audigy SE / ca0106 driver for PowerPC?
After comparing the driver methods to a couple of other PCI drivers that do work on PowerPC , it looks like the methods for accessing the PCI IO space are very depreciated in this driver.. Would it be safe to assume that if I were to modify the existing chip->port = pci_resource_start(pcidev,0); chip->res_port = request_region(chip->port, size); outl(chip->port+MyReg, data); To something like: chip->port = pci_resource_start(pcidev,0); snd_length = pci_resource_len(pcidev, 0); snd_port = ioremap(chip->port, length); outl(port+MyReg, data); I am not sure if I want to leave the outl in there, perhaps a different function, or just a direct assignment? -Russ -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 6:53 AM To: [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org Subject: Re: Audigy SE / ca0106 driver for PowerPC? On Jan 31, 2007, at 6:14 AM, Russell McGuire wrote: > All, > > I recently tried to plugin and use an Audigy SE PCI card with > 2.6.20 and > noticed that it would lock up during driver registration. > > After a little digging, I found that the interrupt routine and a > few other > functions are relying on the x86 inl() / outl() to read from the > sound card. > > Is anyone aware of a PPC port for this driver? Or if it would be > feasible? I > haven't ported a driver between architectures before. > > Or does the inl() / outl() already have PPC equivalent functions > and I need > to be looking for a PCI configuration problem with my system? We implement these on PPC. Clearly we don't have x86 style port IO, usually its handled by memory mapped access to a special region of memory that will be converted into a PCI IO space access. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Audigy SE / ca0106 driver for PowerPC?
All, I recently tried to plugin and use an Audigy SE PCI card with 2.6.20 and noticed that it would lock up during driver registration. After a little digging, I found that the interrupt routine and a few other functions are relying on the x86 inl() / outl() to read from the sound card. Is anyone aware of a PPC port for this driver? Or if it would be feasible? I haven't ported a driver between architectures before. Or does the inl() / outl() already have PPC equivalent functions and I need to be looking for a PCI configuration problem with my system? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Boot w/ VGA console - PCI nvidia
Bill / ALL Thanks for the info. Looking around I see that there is some aged code in the U-boot tree under the MIA board that is a BIOS emulator. Seems like a huge mess to get a video card to turn on. I am using a Freescale MPC8360 so yes, ppc architecture and thus the problems with BIOS emulation with PCI. Do we still need a BIOS emulator if we don't want to run the VGA console during bootup, but only for post boot? I.e. does the NVIDIA driver have enough smarts to initialize the card after Linux is 100% booted up? I really only need to be able to use the graphics card for user applications, and booting with it is not a requirement. If somehow I could boot with the serial console, and then run a user mode application that initiated the card? -Russ Russell McGuire wrote: > Next I have plugged in a nVidia GeForce FX5200 PCI card, > and compiled in the nvidafb driver. > > I can see clearly the PCI card is being detected and the > nvidiafb driver is being registerd, it can even detect > the monitor I have connected. > > However, when I enabled the kernel to use the framer > buffer console, by compiling in that feature, it just > 'seems' to hang after the console_init call. Hi Russ, I got to the same point last year with an ATI PCI card on a MPC8560 system. At this stage, I believe that to get the card displaying graphics you will need to run the card's Video BIOS to initialise the card correctly. I'm guessing that you are running a PPC cpu :-) and that the FX5200 is a consumer x86 graphics card. If so, the Video BIOS will be x86 instructions and you will need to run it with an emulator. A company called SciTech is maintaining an x86emu project for doing this: http://www.scitechsoft.com/products/dev/x86_emulator.html I believe that Xorg also has a x86emu module, so I was going to see if I could get an Xorg installation going and let it do it's magic. For us, getting Xorg running would prove the graphics capability of our platform and we can start writing a GUI. Then it would be just a matter of getting uBoot to display something during boot to keep the customers happy... Bill ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
FW: Boot w/ VGA console - PCI nvidia
All, I have finally got my linux kernel up and working and was able to log in via the serial port, i.e. console=/dev/ttyS0, Using root file system over NFS. Everything seems to work fine, thanks to Leo and Kumar for pointing me to the right /git/ tree. Next I have plugged in a nVidia GeForce FX5200 PCI card, and compiled in the nvidafb driver. I can see clearly the PCI card is being detected and the nvidiafb driver is being registerd, it can even detect the monitor I have connected. However, when I enabled the kernel to use the framer buffer console, by compiling in that feature, it just 'seems' to hang after the console_init call. I know I am missing something with either a 'bootargs' variable, or perhaps a mis-configured set of compile options, i.e. perhaps to many frame buffer drivers inside the kernel that may conflict??? Does anyone have a 101 on how to enable basic 640x480 or 800x600 using either the nvidiafb or perhaps a more rudimentary driver, vga only? Thanks, -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
8360 UCC_GETH INIT_WORK compile error
Kumar / ALL, I was having problems compiling the UCC_GETH driver for 8360. INIT_WORK declared with 2 parameters instead of 3. Googling around, I noticed that somebody posted a temporary patch back in December 14, 2006. Has this been resolved? I am not able to boot the 2.6.19.2 Kernel the moment since the Ethernet/UCCF driver won't compile. -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8360E Linux and 2.6.19.2
I have tracked my 'lockup' to a specific line in /powerpc/kernel/prom.c In the function: __init unflatten_device_tree(void) On line: mem = lab_alloc(size + 4, __alignof__(struct device_node)); mem = (unsigned long) __va(mem); ((u32 *)mem[size / 4] = 0xdeadbeef; This is causing a lockup when 0xdeadbeef is written. I have no idea why... My assumption would be that somehow the memory is not ready? Or BATS are not setup correctly? Perhaps a LAW register? Is this line dependent on having the DTS tree setup correctly? If so, how big can the 'memory' node be in the DTS file? I have mine tried a single bank of 256MB, and of 512MB -Russ -- Original Message: All, Trying to boot up / debug my board with a Rev 1.2 MPC8360E. After the kernel launches from U-boot I receive no serial debug, and the system hangs. I am running U-boot 1.1.6. Dirty , I have walked through the DTS/blob file, after U-boot modifies it, , and can clearly see that the /chosen node, etc.. is getting entered. My original DTS file already has all of the clock speeds entered . I have limited debug ability via some GPIO leds on our board, I can see that the kernel starts to run and at least gets to the point where it clears all the BATs , at which point I lose access to the IO space and can no longer write out to the debug lights. Unfortunately I do not have access to a COP debugger at this point. It doesn't seem to get to the platform files, or at least I can get the GPIO access inside the IMMR space to work correctly. Does anyone have any suggestion per software only debug method that might be enabled? Or a way to temporarily hack the early serial output so I can see what is going on? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8360E Linux and 2.6.19.2
All, Trying to boot up / debug my board with a Rev 1.2 MPC8360E. After the kernel launches from U-boot I receive no serial debug, and the system hangs. I am running U-boot 1.1.6. Dirty , I have walked through the DTS/blob file, after U-boot modifies it, , and can clearly see that the /chosen node, etc.. is getting entered. My original DTS file already has all of the clock speeds entered . I have limited debug ability via some GPIO leds on our board, I can see that the kernel starts to run and at least gets to the point where it clears all the BATs , at which point I lose access to the IO space and can no longer write out to the debug lights. Unfortunately I do not have access to a COP debugger at this point. It doesn't seem to get to the platform files, or at least I can get the GPIO access inside the IMMR space to work correctly. Does anyone have any suggestion per software only debug method that might be enabled? Or a way to temporarily hack the early serial output so I can see what is going on? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Who's the maintainer for the freescale MPC8349ITX board?
Bruce, Did you ever get linux to boot up? I am wondering if I am having similar problems on my system, though it is based on the MPC8360E. Serial port code and clocking is the same between these systems, at least it should be. I am using Linux 2.6.19.2, and U-boot 1.1.6-dirty, though I think it 'mostly' U-boot 1.2.0 equivalent code, as 1.2.0 was released about a day after I downloaded it. I also can generate a 8360.blob file, and when I attempt to boot into the kernel, it hangs with ZERO serial output, even though early serial is defined. -Russ > > Per Grant's suggestion I changed it to: > > 'dtc -I dts -O dtb -V 0x10 mpc8349emitx.dts > 8349.blob' > > > I get a 0 length 8349.blob file using the above. Have you tried -f? > > Kim Hum, interesting. I get a blob of about 4K when I do it. Oh, ooops. Sorry. I did have to modify the *.dts file to get it to compile. There was an error because there wasn't a 'linux,boot-cpu' entry in the cpu node. Adding the '-V 0x10' changed the behavior and I now seem to be hanging in __delay() in serial8250_console_putchar(). Seems maybe the kernel is (at least partially) up but I've got no console port. There may have been a version issue. The DTC I'm using defaluted to a version 3 of the device tree. I think I'm getting further in the kernel booting process (haven't had a chance to really debug it yet) than I was now that I'm telling DCT to generate a version 0x10 device tree. I'm thinking this is a u-boot/*.dts file problem. The *.dts files isn't complete and/or u-boot 1.1.6. isn't finishing filling in the device tree as expected. I think now my problem is that the *.dts file expects u-boot to fill in the 'clock-frequency' node in the serial ports and it's not doing so. Timur indicates 1.1.6 doesn't support this board and I should move to 1.2. Kumar also suggested this (even though I thought he was suggesting I go backwards ;) sorry for the confusion Kumar) so I think I'll give it a try. I appreciate all the help from here, but since it seems more u-boot-ish than kernel I'm going to switch this to the u-boot list. Seems more appropriate. If I find there are problems with the *.dts file, I'll push that back here since they're part of the kernel tree. Thanks again for the help. Bruce ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
DTC compilations
All, Thanks for those who helped me past ARCH-ppc stuff, kernel compiles fine now. Next question, I am using the latest DTC from jdl.com to compile up a sample .dts file. I noted that all the .dts files in the /arch/powerpc/boot/dts do not contain a /chosen node. So if I compile any of them, I get an error and no resulting blob file. Do I have the wrong version of the DTC? Or is this a new feature that I need to implement add to the .dts file I create? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MPC83xx: ns16550.c - 'SERIAL_PORT_DFNS' undeclared?
Ben, That could be the problem I am building using ARCH=ppc What is the difference between the two? -Original Message- From: Ben Warren [mailto:[EMAIL PROTECTED] Sent: Friday, January 19, 2007 11:58 AM To: Russell McGuire Cc: linuxppc-embedded@ozlabs.org Subject: Re: MPC83xx: ns16550.c - 'SERIAL_PORT_DFNS' undeclared? Russell, On Fri, 2007-01-19 at 11:28 -0800, Russell McGuire wrote: > > arch/ppc/boot/common/ns16550.c error: 'SERIAL_PORT_DFNS' undeclared > here .. > I don't think you should be building any code there... Are you using ARCH=powerpc (you should be) regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC83xx: ns16550.c - 'SERIAL_PORT_DFNS' undeclared?
All, Attempting to compile the kernel with that latest DENX-2.6 tree from git. I have started with the MPC834x_defconfig and added a few options, but now when I compile arch/ppc/boot/common/ns16550.c error: 'SERIAL_PORT_DFNS' undeclared here .. I can see clearly this is defined in /include/asm-ppc/serial.h But why isn't this being included? I am more inclined to think this is an option I have not included in my .config file, does anyone have idea what this might be? I do have defined 8250/16550 char/serial devices selected in the menuconfig. Or is this something that changed with the newest patches? I don't seem to recall having this problem with 2.6.15 that shipped with ELDK_4.0, but then again I might have had different compile options defined. Has anyone else seen his error? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8360E - Linux Kernel Suggestions
All, I am beginning to build a kernel for a custom MPC8360E board. Are there any suggestions for which kernel to use, or closest configuration files that might be a good jumping point? I do see a mpc8360Emds.dts file, that I will be starting with, but I don't see any pre-existing MPC836x board '.config' files submitted in the 2.19.2 kernel tree yet. Anyone out have any startup suggestions? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8360E Startup - CFG_INIT_RAM
Anybody, I am porting U-boot to a new custom MPC8360E based board. I have downloaded the GIT U-boot tree, and see that DENX has made an example for the MPC8360E-MDS board, and it is an excellent start. My question lies with what value to place in the CFG_INIT_RAM address. I see that the example board has this mapped to dcache? I think... If so how does one calculate what address dcache sits at? Or would I be able to use the internal IMMR space multi-user QE ram? My question is without dissecting the assembly at startup, does the IMMR get remapped before or after the CFG_INIT_RAM is used. The board has no external memory other than DDR, so I am going to have to use something in the CPU. Due to the massive amount of flash on our board <128M>, I cannot leave the .text space at 0xFE0. So I would prefer the IMMR be located at 0xF000 and flash be at 0xE000, this would leave room for future expansion , if this is even related to early startup. -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
GNU and Freescale MPC83xx / e300 core support?
Thanks all... The author of that comment humbly apologizes for his ineptitude on the FPU. It would appear both cores have the same number of execution units, i.e. 5 So David, I guess in all this the only real difference seems to be the bus architecture, raw clock speed, and perhaps a few new instructions. I checked both manuals this morning and they do differ in some small ways. * 603e, up to 4 instructions in the pipeline, only 3 being complete per clock * e300, up to 5 instructions in the pipeline, still only 3 being completed or start per clock. * Add/compare instructions are now executed in the IU unit instead of the load/store unit. May be the same, but wasn't specific in earlier 603e manuals. * One more HID0 bit than G2, ability to interrupt based on cache parity error * new icbt instruction, instruction cache initialization So there is a section inside the 8360E manual that outlines the specific enhancements. "Features specific to the e300 core not present on the G2 processors follow:" Page 1-5. So I guess my question is back up, does anyone know if an optimized compiler would offer any noticeable performance enhancements in regards to these changes? Other than the obvious instruction being added? Thanks -Russ -Original Message- From: Dan Malek [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 4:33 AM To: Russell McGuire Cc: 'David Hawkins'; linuxppc-embedded at ozlabs.org Subject: Re: GNU and Freescale MPC83xx / e300 core support? On Mar 7, 2006, at 12:52 AM, Russell McGuire wrote: > . The most obvious core difference is > the Floating Point unit; the MPC8280, 603e or G2LE core had no floating > point ability at all. I just want to state for archive purposes this simply isn't true. All of those processors had hardware FPUs. If you would take a few seconds and read the product overviews for these parts, you can make your own informed decision. The person you are talking to doesn't seem to have all of the facts in order. -- Dan
GNU and Freescale MPC83xx / e300 core support?
All, Our meetings with Freescale were aimed specifically at the differences between the MPC8280 and the MPC8360E. The most obvious core difference is the Floating Point unit; the MPC8280, 603e or G2LE core had no floating point ability at all. I am not sure if its core support or not, but I know the MPC83xx line up has drastically altered the bus architecture inside the chips. There are more DMA engines now, and things like the DDR SDRAM bus and 60x / local Bus are separated to run in parallel. Previously, in the 8260/8280 they were mutually exclusive for bus cycles. Internally the shared bus now operates at the DDR frequency, shortly to be DDR2 frequency for later masks. We should see a very large performance improvement for memory intensive applications. Same applies to the PCI 2.2 bus; it was also given separate pins and DMA engines. According to the Freescale FAE the chip can handle simultaneous bus cycles on all three busses at once. I do not have enough internal knowledge on the compilers to know if this is a specific optimization, but it would definitely hinder performance if we couldn't take advantage of it. Freescale claims their newest revision of Metrowerks is optimized for these newer cores, I guess one could get compile with a version of that and disassemble it. Aside: I know the CPM of the older 82xx lineup has been removed, and so has the optimization for its access to the 32 bit local bus. The QUICC engines have replaced it and now have equal priority to all busses, though this probably has little to do with the compiler. Of random, if anyone is using the 'E' revisions of the 83xx lineup, Freescale is claiming that the encryption engine is almost 10x faster than their previous lineup of sister encryption chips that would normally partner with the MPC8260 and MPC8280 chips. I have another meeting tomorrow with Freescale, I can get more specifics. -Russ -Original Message- From: David Hawkins [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 6:27 PM To: Russell McGuire Cc: linuxppc-embedded at ozlabs.org Subject: Re: GNU and Freescale MPC83xx / e300 core support? Russell McGuire wrote: > I was recently involved in a meeting with a Freescale FAE, which informed us > that the current revisions of the GNU C/C++ compilers do not yet possess any > optimizations for the MPC83xx cores, more precisely no optimizations for the > e300 cores inside the MPC83xx line up. > > They did say it was 100% backwards compatible with the existing 603e / 6xx > core support, so all the code should work just fine. > > I was curious if anyone out there was aware of any efforts to produce / > patch any of the GNU compilers to have optimizations for these newer > MPC83xx's with the e300 cores? > Hi Russ, Out of interest, what are the main differences that optimization would help with? I'm going to take a look at the 8349E, but I'm waiting on the Freescale MDS board. I haven't read the user manual in great detail, other than to check out the potential bus performance, but I thought the main change in the G2 vs e300 core was the cache size. Did they add new instructions, or change the number-of-cycles required for existing instructions? The Freescale document: Freescale PowerPCT Architecture Primer, POWRPCARCPRMRM, Rev. 0.1, 6/2005 Has the following on page 12 of the PDF: e300 Cores and Platform The ongoing presence of the e300 testifies to the longevity of both the PowerPC architecture and the microarchitecture. The e300 was introduced in 1994 as the MPC603, running at 100 MHz, and continues to be proliferated more than a decade later reaching speeds exceeding 600 MHz. The e300 PowerPC core and platform address the low- to mid-range performance needs of the market. The e300 core is an enhanced version of the popular PowerPC 603e core used in previous-generation PowerQUICC II devices that scale from 266 to 667 MHz in 130 nm process technology. Enhancements include twice as much L1 cache as the 603e (32-Kbyte data and instruction caches) with integrated parity checking and other performance-oriented features. The e300 core is fully software-compatible with existing 603e core-based products and provides the processing foundation for the company's new MPC8349E PowerQUICC IIT Pro communications processor family. So I guess the question is what are the 'other performance-oriented features' this statement is referring to? The e300 core reference manual comments: The e300c1core integrates five execution units: an integer unit (IU), a floating-point unit (FPU), a branch processing unit (BPU), a load/store unit (LSU), and a system register unit (SRU). The ability to execute five instructions in parallel and the use of simple instructions with rapid execution times yield high efficiency and throughput for e300
GNU and Freescale MPC83xx / e300 core support?
I was recently involved in a meeting with a Freescale FAE, which informed us that the current revisions of the GNU C/C++ compilers do not yet possess any optimizations for the MPC83xx cores, more precisely no optimizations for the e300 cores inside the MPC83xx line up. They did say it was 100% backwards compatible with the existing 603e / 6xx core support, so all the code should work just fine. I was curious if anyone out there was aware of any efforts to produce / patch any of the GNU compilers to have optimizations for these newer MPC83xx's with the e300 cores? Thanks, -Russ
82xx_io UART BRG's vs BUS CLK
Everyone,
Found a bug in the Linux 2.4.25 -> 2.4.26 and perhaps newer PPC kernels.
However, thanks for the U-boot tree, as it already had the fix. Thanks to
those who had hinted at something like this already. I have tested this out
and it works good for me on a MPC8280, with U-boot 1.1.2 and DENX Linux
2.4.25.
I don't have a patch file but the change is real simple if someone would
like to provide one.
/linux/arch/ppc/8260_io/commproc.c there is this bit of code.
--
/* This function is used by UARTS, or anything else that uses a 16x
* oversampled clock. */
void cpm2_setbrg(uint brg, uint rate)
{
volatile uint *bp;
/* This is good enough to get SMCs running.
*/
if (brg < 4) {
bp = (uint *)&cpm2_immr->im_brgc1;
}
else {
bp = (uint *)&cpm2_immr->im_brgc5;
brg -= 4;
}
bp += brg;
*bp = ((BRG_UART_CLK / rate) << 1) | CPM_BRG_EN;
}
I recently put the correct frequency in U-boot to pass to linux, i.e.
66,666,666Mhz instead of 66,000,000Mhz. And this broke the BRG setups and I
could no longer run 115200 Baudrate.
So after looking around, I found that the Uboot 1.1.2 and newer code already
has a modified version of this code, and that it works correctly. Thanks
DENX!
See correct code below: note the cd--
-
void m8260_cpm_setbrg(uint brg, uint rate)
{
volatile uint *bp;
uint cd = BRG_UART_CLK / rate;
if ((BRG_UART_CLK % rate) < (rate / 2))
cd--;
if (brg < 4) {
bp = (uint *)&immr->im_brgc1;
}
else {
bp = (uint *)&immr->im_brgc5;
brg -= 4;
}
bp += brg;
*bp = (cd << 1) | CPM_BRG_EN;
}
-Original Message-
From: Jenkins, Clive [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 14, 2006 3:24 AM
To: Russell McGuire; linuxppc-embedded at ozlabs.org
Subject: RE: 82xx_io UART BRG's vs BUS CLK
> I did some math on the BRG calculations and with 66Mhz the BRG divisor
is
> 17.8 I am assuming 17 gets written, and with 66.666Mhz then its 18.02
so
> thus 18 probably gets written. Should perhaps a constant minus 1 be
added to
> the code?
> Using:
> U-boot 1.1.2
> DENX Linux 2.4.25
> Is anyone aware of similar issues, or are there bug fixes past the
2.4.25
> Kernel for this?
> -Russ
Hi Russ
I am not familiar with your hardware, nor have I checked the code that
calculated the Baud rate divisor.
I would advise against "adding a constant -1", in favour of rounding
to the nearest integer. From your figures:
divisor = clock / (baudrate * 32)
To get a rounded result using real numbers:
divisor = integer_part_of((clock / (baudrate * 32)) + 1/2)
Using integer arithmetic, you can code this in C as:
divisor = ((clock / baudrate /16) + 1) >> 1;
I would check whether or not the code is doing this, or the equivalent,
and if not, change it. If the code is doing this, the divisor should be
18 in both cases.
Clive
82xx_io UART BRG's vs BUS CLK
Anyone, Recently I found that the value I was passing to Linux for the BUS CLK frequency was incorrect. Previously I was passing in from U-boot (66 * 1000 * 1000) 66Mhz, it had been brought up this can cause incorrect SOF transmission rates with the 82xx USB driver, so after measuring our 'exact' clock, I made the adjustment to ( 66,666,666 Hz ) 66.66Mhz . Hoping this would correct the issue, however now I cannot run the serial console baud rate (on SMC2) any higher than 115200 without corruption, however 57600 works on. This worked great before I changed the U-boot BUS clock to the correct value. I did some math on the BRG calculations and with 66Mhz the BRG divisor is 17.8 I am assuming 17 gets written, and with 66.666Mhz then its 18.02 so thus 18 probably gets written. Should perhaps a constant minus 1 be added to the code? Using: U-boot 1.1.2 DENX Linux 2.4.25 Is anyone aware of similar issues, or are there bug fixes past the 2.4.25 Kernel for this? -Russ
Voyager Video support color depths?
Everyone, I had a question about the various video support that has been tested with the 2.4.25 DENX Kernel. To date I have had pretty good luck with by making sure I have compiled the kernel with the Voyager.h file set at 32 BPP mode. For speed optimization I wanted to cut it back to 16 BPP mode, however I couldn't hardly get it to boot the machine after I did this change by changing '#define SCREEN_BPP 16'. Most attempts the kernel would lock up before a login prompt was available. When I tried SCREEN_BPP at 8 then it booted fine, however QT/Embedded had terrible colors. I was wondering if I should be looking for the trouble in some other code, or perhaps hardware, or if this is a known bug in the SM501 / Voyager driver, or perhaps the linux frame buffer driver. Thanks all, -Russ
Qt, forks and threads = segmentation faults?
Everyone, This is a more general question, and if anyone knows of a more specialized list this should be posted to, I'd be happy to do so... Small picture of hardware: DENX Linux 2.4.25 / PowerPC MPC8280 / 32 MBs of RAM I am using QT Embedded for a small GUI that does BSD sockets, also using DENX's SM501 video driver. Everything is quite stable, recently I added a additional process to the application using fork() for the listening 'accept' call for the sockets. After many tests I decided that due to the nature of the fork() command and the GUI half of the program, that this was a large waste of memory, as I was duplicating the entire GUI system. So I started looking alternatives, and have landed at the 'pthread' library. However, now I have lots of segmentation faults, particularly when I send a message using QT's postEvent commands back to the main thread. I was curious if anyone had any better idea of a more stable or perhaps a suggestion on why I am able to only get about 30 seconds of run time out of the app using pthread, verses fork() seems to be much stabler. -Russ
82xxHCI driver for MPC8280 Specifically
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 0x0A01 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: [EMAIL PROTECTED] [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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: PowerPC reservations To: linuxppc-embedded 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
porting 82xx HCI driver
Everyone, I am attempting to port the 8xx HCI driver over to the MPC8280, and have it compiling... However, there are a few functions that seem to be missing, that are implicitly defined... These are just warnings during a compile but turn up as errors when attempting to load the modules... I was curious if it was just a missing piece of the kernel that I have not included in the build. Here are a few of the functions... stop_sof_timer ack_sof_timer assert_reset board_stop_force_disconnect I have done a complete text search on the kernel source I have for 2.4.25 and haven't turned up anything. Any ideas? -Russ
Getting Perl on Embedded Linux PowerPC
Anyone, I was attempting to get some ATM Tools compiled into the embedded PowerPC, and found I needed Perl installed on the target before I continue. So my question... Has anyone had any luck getting any version of Perl 5 or higher installed onto the file system. I am still running this over the NFS dev environment, and plan to remove it before final production, so space is of no concern at the moment. Or perhaps a pre-compiled RPM that installs, that is built for PowerPC. I am using DENX Linux 2.4.25 at the moment, with pretty much the default root file system that is provided. -Russ
827x/8x Linux USB Host driver
Does anyone know of the existence of an open source USB host driver for the 827x/8x PowerQUIC II processors for Linux 2.4.2x? This CPU introduced a USB host controller inside the CPU vs the 8260, which doesn't have one. Thanks, -Russ
linux and sram
Everyone, If we are using U-boot and populate the CFG_SRAM_SIZE and CFG_SRAM_BASE values, and makes sure this is passed into the kernel. Does Linux 2.4.2x+ have any direct support for this? Is it just added into the regular memory pool? Does it get used for specific tasks? Or is this set aside for custom drivers? Thanks, Russell McGuire
MPC8280 Support for Linux 2.4.25 and up?
Everyone, Are there any known issues with Linux 2.4.25 and supporting the MPC8280 CPU? I have seen some posts in the past, and tried Google'ing for a patch for CPU support, but have only seen tidbits... Seen some support issues for the 5200 as it also runs the G2_LE core. So I guess, I am asking if there are patches, perhaps where? Or should I consider moving up in kernel revisions, to get support for the newer CPM_2 drivers. Any help would be greatly appreciated. Thanks, Russell McGuire
Linux 2.4.25 problems after initrd detected
Hello all, I am running ELDK 3.1.1, Linux version 2.4.25, on a MPC8280 CPU, U-boot 1.1.2 to load linux. This is a new prototype board we are developing; I can include the .config information in a later post, if anyone needs to know something from it. I am using the uRamdisk image, from the denx ftp for the initRd image. I have added a couple lines to the cpuc.c file to add support for the MPC8280 CPU, I think its only that one file, so perhaps linux is not detecting the CPU correctly. Two questions: 1) Does the "Warning: Real time clock stuck" pose any problem to getting the initrd loaded? Or perhaps interrupts? 2) Does the MTD physical mapping driver have to be enabled for the initrd to work, I haven't been able to get my driver to successfully complete a ioremap if I enable it. I am using AMD 32MB flash mapped physically at 0xE000 at least in Uboot. I know the kernel is still marginally alive as I can step into the kernel debugger over the serial port at this point, if I press control C, its in the interrupt routines waiting for UART interrupts. I apologize in advance if I have not provided enough info, as its my first post. Russell McGuire Here is the output, from Uboot. ## Booting image at e008 ... Image Name: Linux-2.4.25 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:661411 Bytes = 645.9 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x021339A0 => set upper limit to 0x0080 ## cmdline at 0x007FFF00 ... 0x007FFF10 bd address = 0x02133FB4 memstart= 0x memsize = 0x0220 flashstart = 0xE000 flashsize = 0x0400 flashoffset = 0x00036000 sramstart = 0x sramsize= 0x immr_base = 0xF000 bootflags = 0x0001 vco =528 MHz sccfreq =132 MHz brgfreq = 33 MHz intfreq =396 MHz cpmfreq =264 MHz busfreq = 66 MHz ethaddr = EA:53:0E:4B:8A:46 IP addr = 192.168.5.50 baudrate= 115200 bps ## Loading RAMDisk Image at e020 ... Image Name: Simple Embedded Linux Framework Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:1400198 Bytes = 1.3 MB Load Address: Entry Point: Verifying Checksum ... OK ## initrd at 0xE0200040 ... 0xE0355DC5 (len=1400198=0x155D86) Loading Ramdisk to 01fdd000, end 02132d86 ... OK ## Transferring control to Linux (at address ) ... Memory BAT mapping: BAT2=32Mb, BAT3=2Mb, residual: 0Mb Linux version 2.4.25 (root at FedoraCore2) (gcc version 3.3.3 (DENX ELDK 3.1 3.3.3-8)) #94 Tue Jul 5 18:59:08 PDT 2005 On node 0 totalpages: 8704 zone(0): 8704 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram rw Warning: real time clock seems stuck! Calibrating delay loop... 263.78 BogoMIPS Memory: 31472k available (1128k kernel code, 372k data, 56k init, 0k highmem) Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode cache hash table entries: 4096 (order: 3, 32768 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc. CPM UART driver version 0.01 ttyS0 on SMC1 at 0x, BRG7 ttyS1 on SMC2 at 0x0040, BRG8 ttyS2 on SCC1 at 0x8000, BRG1 ttyS3 on SCC2 at 0x8100, BRG2 eth0: FCC2 ENET Version 0.4, EA:53:0E:4B:8A:47 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 4096) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1367k freed VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 56k init <-- No more output, unless control C is pressed and "sometimes" it will enter into the KGDB.
8260 ATM drivers / stack
I saw a while back on this list that some users had posted some luck with getting the ATM drivers to work on an 8260. I am currently working on getting the ATM stack to work with an 8280 CPU. I think this was back in like '02. Was wondering if any of those people, or others with similar experience were still participating on this mailing list. Would appreciate any pointers, etc.. -R. RcGuire
