understanding an IO question
I have a board using an 8541 which is based on the mpc85xx_cds bsp. It has one PCI device connected to the 8541, an ASIC we make that maps in resources for its registers at 0x8400_ - 0x8400_0038. The driver for our ASIC works in an 8241 design and I am trying to get its register access working in the 8541 and need a little additional understanding. I can see in cat /proc/iomem where we have memory apparently allocated for our registers, like this. cat /proc/iomem 8000-9fff : PCI1 host bridge 8400-8438 : ichar 8800-8fff : ichar e0003000-e00030ff : fsl-i2c.1 e0004500-e0004507 : serial In our driver, I do an ioremap_nocache with 0x8400_ as an argument to the ioremap and am returned a virtual address of the form 0xc905_8000. Unfortunately, I cannot seem to access my registers as they all return zero when accessed with the iowrite32/ioread32 helper functions. A little further. We do use the Outbound Address Translation window feature in the 8541 to get to our PCI device and I do set this up in uboot and I can read and write registers on our ASIC from uboot. Its just in the Linux driver that I seem to be having trouble. So,... I am hoping someone could give me a couple of pointers on where to look next for the missing piece of why I cannot access the registers on our ASIC from Linux whereas things were working fine from uboot before booting Linux. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: understanding an IO question
I apologize for not making myself clearer. This is a kernel driver
issue, not a user space issue. The issue is addressing the registers in
a PCI device in its driver.
We have a functioning code base that works with Linux 2.6.17.11 on our
8241 platform. We have built a new board using the 8541. Although the
registers are addressable from uboot and can be read/written, once Linux
boots, the registers cannot be addressed.
I suspect this to be in either TLB1 setup or Outbound Address
Translation windows.
So,... my questions really are
1. "Where are the TLB's setup in the 85xx chip during Linux
initialization for devices that may be using PCI memory in the
0x8000_ - 0x9fff_ address space region?". I can see that some
reset of TLB's occurs in head_fsl_booke.S and perhaps that is part of
the answer. The other part may be in where TLB's are then setup again
after they are reset in Linux.
2. "Are Outbound Address Translation windows reset by the arch/ppc/...
Linux initialization and if so, where. If they are reset, where is the
best place to put them back to the state I had set them up in uboot.
Charles
-Original Message-
From: Ami Levi Waves [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 12:51 AM
To: Charles Krinke; linuxppc-embedded@ozlabs.org
Subject: RE: understanding an IO question
The way we do it:
Fisrt open a memory device:
Handle = open("/dev/mem", O_RDWR);
Than map the address using:
mmap(NULL, nAdress, PORT_READ | PROT_WRITE, MAP_SHARED, Handle,
your
base address);
mmap returns a virtual pointer, pointing to your HW.
Ami
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-
> [EMAIL PROTECTED] On Behalf Of Charles Krinke
> Sent: Wednesday, February 21, 2007 2:14 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: understanding an IO question
>
> I have a board using an 8541 which is based on the mpc85xx_cds bsp. It
> has one PCI device connected to the 8541, an ASIC we make that maps in
> resources for its registers at 0x8400_ - 0x8400_0038.
>
> The driver for our ASIC works in an 8241 design and I am trying to get
> its register access working in the 8541 and need a little additional
> understanding.
>
> I can see in cat /proc/iomem where we have memory apparently allocated
> for our registers, like this.
>
> cat /proc/iomem
> 8000-9fff : PCI1 host bridge
> 8400-8438 : ichar
> 8800-8fff : ichar
> e0003000-e00030ff : fsl-i2c.1
> e0004500-e0004507 : serial
>
> In our driver, I do an ioremap_nocache with 0x8400_ as an argument
> to the ioremap and am returned a virtual address of the form
> 0xc905_8000. Unfortunately, I cannot seem to access my registers as
they
> all return zero when accessed with the iowrite32/ioread32 helper
> functions.
>
> A little further. We do use the Outbound Address Translation window
> feature in the 8541 to get to our PCI device and I do set this up in
> uboot and I can read and write registers on our ASIC from uboot. Its
> just in the Linux driver that I seem to be having trouble.
>
> So,... I am hoping someone could give me a couple of pointers on where
> to look next for the missing piece of why I cannot access the
registers
> on our ASIC from Linux whereas things were working fine from uboot
> before booting Linux.
>
> Charles
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: understanding an IO question
You have to use ioremap() to get TLB and page mappings for any IO. We setup some initial kernel mappings to allow access to system memory but thats it. Everything else should go through some mapping function. > 2. "Are Outbound Address Translation windows reset by the arch/ppc/... > Linux initialization and if so, where. If they are reset, where is the > best place to put them back to the state I had set them up in uboot. Nope, currently the address translation windows at the system level are not touched by arch/ppc (unless done in your own code). Have you tried plain old ioremap() [not _nocached] ? Dear Kumar: I hope all is well with you and I appreciate your taking time to have a mini-dialog with me today. Here's the deal. First of all, we are using the linux-2.6.17.11 code base from kernel.org, which was the latest one when this project started. We have validated that our driver, with no modifications, works fine on our existing production 8241 board with this kernel. This driver does use ioremap_nocache(), request_region() and other common driver-type calls, so I suspect the issue is the kernel is not setup quite right for the driver, not that the driver needs modification for the kernel. Starting from that premise, I know that we depend on outbound address translation windows and any necessary TLB setup to get access to the CPU address region around 0x8400_. The reason for the outbound address translation windows has to do with the fact that we use a DAC (Dual Address Cycle) to a 64bit PCI address at 0x1__ or 0x3__ depending on whether we are writing/reading to the window at 0x8800_ or 0x8400_. One thing that puzzles me is that a 'cat /proc/iomem' shows a PCI window is setup in Linux, like this >> cat /proc/iomem >> 8000-9fff : PCI1 host bridge I don't see anywhere in the Linux-2.6.17.11 code base where this window is setup. Perhaps you could point me towards the section of code where this is done. On the ioremap()/ioremap_nocache() issue. I did look at the source in the kernel for ioremp_nocache() and it is #defined to be ioremap(), so I think it is safe to assume they are the same. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: understanding an IO question
Thanks Kumar. Let me gnaw on these notions over the next few days and I will probably come back and ask another question or two, but now I have enough meat to go look into what is happening in the Linux initialization. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: understanding an IO question
Dear Kumar: Thank you very much for your advice on addressing our PCI device. It turned out that the OutboundTranslation windows were the key. In uboot, I setup two windows to allow accesses to 32bit cpu space 0x8400_000 & 0x8800_ to be translated to 64bit DAC (Dual Address Cycles) at 0x3__ & 0x1__ respectively, and both the 8241 and 8541 do this quite well. Once the potar, powbar and other outbound translation address windows were reset to the same values in Linux that they had in uboot, outbound transactions work fine and address the registers and memory in our ASIC. Next, I need to study the difference between the DMA engines in the 8241 and 8541 to accomplish a similar mission. This one may be a bit trickier and you advice would be greatly appreciated. The 8241 DMA engine understands 64bit DMA in that it has a high source & destination address register for the upper 32bits of a 64bit address. Unfortunately, the 8541 does not. It only supports 32bit DMA. So, my assumption is that there is some way to use a different outbound address translation window and emulate 64bit DMA transactions using the 32bit DMA engine in the 8541. I don't know if you have studied this part at all, but if you or anyone would be willing to offer a few hints, I would be appreciative. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
using gdb/kgdb
I am having a little trouble with kgdb in an 8541 kernel. The kernel is compiled with CONFIG_DEBUG_KERNEL, CONFIG_KGDB, CONFIG_KGDB_TTYS1 all defined and I can boot it to the point where it is waiting for a gdb connection and it does make a connection. I have kernel command line that contains "kgdb=ttyS1,115200,halt kgdbwait" in it and this appears to be working fine and the output looks like this. MMU:enterJCSSU'ëinit MMU:mapin MMU:setio MMU:exit begin start_kernel setup_arch: enter setup_arch: kgdb breakpoint At this point, from the cross-compiled gdb on a host, if I invoke gdb with vmlinux as an argument, the PC is zero. $ ppc-gdb vmlinux (gdb)set remotebaud 115200 (gdb)target remote /dev/ttyUSB0 (gdb)0x in ?? () If I invoke the cross-compiled gdb without vmlinux as an argument, I get a better looking pc, like this $ ppc-gdb (gdb)set remotebaud 115200 (gdb)target remote /dev/ttyUSB0 (gdb)0xc00071f4 in ?? () But in neither case can I 'step' or 'next' as gdb merely replies Cannot find bounds of current function. Can someone offer a spot of advice to this despicable condition? Charles p.s. I apologize if this comes out html as I am using the companies webmail interface from home. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
CPM FCC1 & FCC2
In our design for an 8541 board, we are going to be using FCC1 & FCC2 in addition to the FAST controller. I have been looking through the Linux-2.6.17.11 source we are using and although I can find some references to MPC85xx_CPM_FCC1, I cannot quite identify the driver used with the 85xx in Linux. Can someone help me determine the name of the appropriate driver for the two FCC sections of the 8541 please? Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: debugging custom Xilinx boot loader with abatron and Montavistadevrocket
Dear Wade: Since the MontaVista engineers have no clue as to how to use their product, and I had the same experience, the appropriate solution is to abandon their product until and unless they do have a clue as to how to use their IDE. The route using DDD/gdb is an appropriate one and building an .elf file is no problem with either uboot or Linux. Another thing to watch out for with Montavista is their gdb executable may or may not work correctly. If this is the case, you will need to get a gdb from gnu.org and cross compile it. Basically, they blew it on the toolchain also. Charles From: [EMAIL PROTECTED] on behalf of Wade Maxfield Sent: Sat 2/24/2007 2:40 PM To: ppc Subject: Re: debugging custom Xilinx boot loader with abatron and Montavistadevrocket Thanks! I did indeed mean to say "devrocket" when I said "MontaVista" I went down the DDD/gdb route using the MontaVista command line tools. Their ppc_405-gdb connects to the abatron bdi2000 as a gdb server. I was able to get that to work to some extent. I did not ask my main question correctly enough. Let me rephrase. My main question (for the MontaVista experts out there) is either 1) In DevRocket, what kind of project do you choose to debug an externally build .elf file? MontaVista support engineers had no clue. or 2) How do you use DevRocket to create a cross compiled set of code linked to a specific address. MontaVista support engineers also had no clue on this one. If either answer is no, OK. Now that I have the DDD/gdb/Abatron complex working, I don't think I absolutely need the DevRocket and its nice (but slow) facilities. It would be nice to do the cross compile under DevRocket, but the Xilinx EDK is doing just fine. I will look into uboot later, when I do another attempt at getting linux into the system. I failed to mention that we have the system ace chip with a compact flash card, and it is apparently functional. It provides all the "flash" that we need. We do have some onboard flash for configuration data. Our project is simultaneously complex and simple. It is complex in what it does ( a complicated receiver based on latest DSL technology), but simple in the household chores (linux is almost overkill, but we do need ethernet and all that implies). Interesting we can get PPC linux into 16 meg. Once that happens, I'll try it again. thanks, wade On 2/23/07, Jeff Angielski <[EMAIL PROTECTED]> wrote: On Fri, 2007-02-23 at 10:11 -0600, Wade Maxfield wrote: > > I want to debug a ppc custom boot loader with Montavista (since we > spent the money on it) under the Xilinx fx60. Writing custom bootloaders is nontrivial. Are you sure you really want to do that? And what does MV have to do with the bootloader? -- Jeff Angielski The PTR Group ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: using gdb/kgdb
> At this point, try setting the architecture as below (you can show the current architecture first, to check that it is wrongly set to "e500", which doesn't work properly) (gdb) show architecture The target architecture is set automatically (currently powerpc:e500) (gdb) set architecture powerpc:common The target architecture is assumed to be powerpc:common > (gdb)target remote /dev/ttyUSB0 > ... More explanation can be found here: http://www.ultsol.com/faq_p311.htm [I would prefer to reference an explanation on this mailing list, but I did not find one.] I hope this solves your problem. Clive Dear Clive: I appreciate your kind comment, but I think I have already accommodate this by using the latest gdb and cross-compiling it and it starts up in architecture powerpc:common. There must be something else going awry here and I wonder what other things might cause the pc to be unreadable and uncontrollable from gdb. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: using gdb/kgdb
Dear Clive After all is said and done, it turns out your original architecture was the issue. Given a new gdb-6.6, cross compiled for ppc, the incantations are: >From uboot Uboot> setenv bootargs kgdb=ttyS1,115200 kgdbwait Uboot> tftp 100 uImage Uboot> bootm 100 $ddd -debugger ppc_85xx-xgdb vmlinux (gdb) set verbose on (gdb) set architecture powerpc:common (gdb) set remotebaud 115200 (gdb) target remote /dev/ttyS0 (gdb) break do_fork (gdb) cont Gdb does break at do_fork. It can break on the next line or continue to the next line with no problem. What it doesn't do is step. When I try to tell it to step, it looks like it never completes the step function. But in any case, Clive, thank you very much for getting me to this point. The next place is to figure out the step command. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
CONFIG_BDI_SWITCH & -g
Good morning. I recompiled my linux-2.7.17.11 kernel with CONFIG_BDI_SWITCH removed and now can step & next. I can also break on sys_init_module where a module is loaded and its init routine invoked. Can someone confirm the factoid that CONFIG_BDI_SWITCH may have something to do with precluding step & next from a gdb/kgdb connection across a serial port? Also, it looks like the module I am interested in is not compiled with debug info even through CONFIG_DEBUG_INFO is defined and -g is put into CFLAGS in the top level Linux Makefile. I say this because ppc_85xx-objdump -S module.ko does not show source lines. Can some confirm that there is another setting somewhere to compile a module in drivers/... with debugging info so I can step through its module_init routine. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
To DMA or not to DMA
I am in the midst of "trying" to get DMA working in a driver on a new 8541 board using Linux-2.6.17.11. I am starting with a functional driver on an 8241. One of the issues seems to be the difference between the DMA engines in the 8241 vs the 8541. Our PCI device uses DAC (Dual Address Cycles) to write to a 64bit memory space using a 32bit PCI interface and this works just fine on both the 8241 and the 8541. On both processors, the outbound address translation windows are used to create the DAC. On the 8241, its DMA engine can create DAC's to 64bit PCI address space on a 32bit PCI interface with no problem. The problem occurs in that the DMA engine in the new 8541 will not produce DAC's. Rather it looks like one must DMA to an outbound window and let the address translation logic do the DAC. With this in mind, I am using POTAR2 and its cousins for access to memory on our PCI device. In the DMA logic, I do (in pseudocode) origPotar = readl(POTAR2) //save outbound address translation writel(0x0004, SATR0) //source attribute for normal read/write writel(0x0004, DATR0) //dest attribute for normal read/write writel(destHigh32bits >> 8, POTAR2) //put address into window considering the bit shifting required writel(destLow32bits, DAR0) //setup the destination address register writel(sourceLow32bits, SAR0) //setup the source address register writel(size, BCR0) //setup the number of words to transfer writel(1, MRx[CS]) //trigger the DMA to go writel(origPotar, POTAR2) //restor outbound address translation And I would expect the DMA to work, but it doesn't. Can someone help me get my mind around how the DMA in the 8541 is supposed to work? Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
DMA take 2
Let me try my DMA question a bit more concisely to the linuxppc group. I am working on a DMA routine for the 8541 and the status register ends up with the CB (ChannelBusy) bit set, which I suspect is a programming error on my part. So, the question is: "What are the common programming errors that lead to SR0[CB] set at the end of a DMA transaction in an 8541?" Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
DMA take 3
Dear Ed:
Thank you for the two hints. Please bear with me for another question or two as
I try to converge this today.
I have incorporated your two ideas and still have something else going awry.
First of all, I do not have to be changing a POTAR at this point in the program
for a while. So I am trying to simplify it until it works. Here is the current
state.
write(0, SR0) //clear anything and everything
write(0x0004, SATR0) //READTTYPE=Read, do not snoop
write(0x0004, DATR0) //READTTYPE=Write, do not snoop
write(sourceLow32bits, SAR0) //usually 0x07xx near the top of 128Mbyte
physical memory
write(size, BCR0)
printk(various things including some of the registers recently written
//I am assuming this is benign in a Linux driver at this point
asm("sync") //got this in here now
write(destLow32bits, DAR0) //This should now trigger the DMA
//potar already has the destHi32Bits and it is always 0x1__ in 64bit
memory space in
//At this point, I would expect the DMA engine to DMA through the window
previously setup in potar
Charles
From: Swarthout Edward L-SWARTHOU [mailto:[EMAIL PROTECTED]
Sent: Fri 3/2/2007 11:28 AM
To: Charles Krinke; linuxppc-embedded@ozlabs.org
Subject: RE: To DMA or not to DMA
It could be a lot of other things, but I see two things wrong:
> From: Charles Krinke
...
> origPotar = readl(POTAR2) //save outbound address translation
> writel(0x0004, SATR0) //source attribute for normal read/write
> writel(0x0004, DATR0) //dest attribute for normal read/write
> writel(destHigh32bits >> 8, POTAR2) //put address into window conside
> writel(destLow32bits, DAR0) //setup the destination address register
> writel(sourceLow32bits, SAR0) //setup the source address register
> writel(size, BCR0) //setup the number of words to transfer
Add a sync here to ensure the previous stores are out of the cpu.
> writel(1, MRx[CS]) //trigger the DMA to go
> writel(origPotar, POTAR2) //restor outbound address translation
Don't destroy the outbound window brefore the dma is complete!
> And I would expect the DMA to work, but it doesn't. Can someone help
me
> get my mind around how the DMA in the 8541 is supposed to work?
-EdS
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: DMA take 3
Thanks again Ed. This is a really good idea. It is entirely possible that some
other complication in Linux is getting to me.
So, with that in mind, I'm off to uboot for a while to see if I can convince
myself the rest of the chips are setup correctly on the board.
Charles
From: Swarthout Edward L-SWARTHOU [mailto:[EMAIL PROTECTED]
Sent: Fri 3/2/2007 1:27 PM
To: Charles Krinke; linuxppc-embedded@ozlabs.org
Subject: RE: DMA take 3
Maybe even a more basic question - are you setting the controller up
correctly for this mode (SRW=1 and CTM=1)?
One suggestion is to try it once by hand in u-boot to ensure the
hardware is working as expected before trying it in Linux.
-EdS
#simple u-boot Direct Mode dma example - Ed.Swarthout
setenv sad fff8 #source
setenv dad 1#dest
setenv bc 10#byte count
setenv b e0021 #ccsr
mw ${b}104 #sr clear
mw ${b}110 5#satr SREADTTYPE=5 read snoop
mw ${b}114 $sad #sar
mw ${b}118 5#datr write snoop
mw ${b}120 $bc#bcr
mw ${b}100 0f03c404 #mr BWC=f, DAHTS=3, SAHTS=3, SRW=1 CTM
md $dad 5 #before
mw ${b}11c $dad #set dar and go
md ${b}100 9#show status
md $dad 5 #after
Or make a dma command and run it:
setenv dma 'mw ${b}104 ;mw ${b}110 5;mw ${b}114 $sad;mw
${b}118 5;mw ${b}120 $bc;mw ${b}100 0f03c404; mw ${b}11c $dad; md
${b}100 9'
setenv b e0021; setenv sad fff8; setenv dad 1; setenv bc 10
run dma
--- results ---
=> md $dad 5
md $dad
0001: deadbeef deadbeef deadbeef deadbeef
00010010: deadbeef
=> run dma
run dma
e0021100: 0f03c405
e0021110: 0005 fff80010 0005 00010010
e0021120:
=> md $dad 5
md $dad 5
0001: 27051956 552d426f 6f742031 2e322e30'..VU-Boot 1.2.0
00010010: deadbeef
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: DMA take 3
Dear Ed:
Your uboot script works fine with the DMA engine. I can transfer a few bytes
from 0xfff8_ to 0x1_ with no difficulty. However, I have not yet gotten
to an understanding when DMA'ing through an address translation window, but at
least I know how to make it work in local memory (LM) space.
In our design, we have two outbound translation address windows setup and the
BAR's in our ASIC are dual, meaning BAR0/BAR1 work together to form a 64bit
address and BAR2/BAR3 work together to form a different 64bit address. One is
translated from 0x8400_ to 0x3__ which we call RM (Register Memory)
and the other is translated from 0x8800_ to 0x1__ which we call SM
(System Memory).
I have setup POWBAR1/POTAR1/POWAR1 for the 0x8400_ translation and
POWBAR2/POTAR2/POWAR2 for the 0x8800_ translation. Using those
translations, we can write & read single memory locations in both RM & SM space
from LM space using these settings.
Next is the burst mode of the PCI for which, I believe, the only recourse is to
use the DMA engine. Here things get a bit trickier.
I am DMA'ing to the window at 0x8800_ plus the destination offset within
that window and the issue is that although LM->LM DMA is now working, LM->SM is
not working.
So, her are the questions:
Is there any special consideration in trying to DMA from a 32bit PCI to a 64bit
address using DAC (Dual Address Cycles) in the 8541?
Are there any special considerations relating to using an outbound address
translation window to do this?
Where else might things be going awry?
Charles
From: Swarthout Edward L-SWARTHOU [mailto:[EMAIL PROTECTED]
Sent: Fri 3/2/2007 1:27 PM
To: Charles Krinke; linuxppc-embedded@ozlabs.org
Subject: RE: DMA take 3
Maybe even a more basic question - are you setting the controller up
correctly for this mode (SRW=1 and CTM=1)?
One suggestion is to try it once by hand in u-boot to ensure the
hardware is working as expected before trying it in Linux.
-EdS
#simple u-boot Direct Mode dma example - Ed.Swarthout
setenv sad fff8 #source
setenv dad 1#dest
setenv bc 10#byte count
setenv b e0021 #ccsr
mw ${b}104 #sr clear
mw ${b}110 5#satr SREADTTYPE=5 read snoop
mw ${b}114 $sad #sar
mw ${b}118 5#datr write snoop
mw ${b}120 $bc#bcr
mw ${b}100 0f03c404 #mr BWC=f, DAHTS=3, SAHTS=3, SRW=1 CTM
md $dad 5 #before
mw ${b}11c $dad #set dar and go
md ${b}100 9#show status
md $dad 5 #after
Or make a dma command and run it:
setenv dma 'mw ${b}104 ;mw ${b}110 5;mw ${b}114 $sad;mw
${b}118 5;mw ${b}120 $bc;mw ${b}100 0f03c404; mw ${b}11c $dad; md
${b}100 9'
setenv b e0021; setenv sad fff8; setenv dad 1; setenv bc 10
run dma
--- results ---
=> md $dad 5
md $dad
0001: deadbeef deadbeef deadbeef deadbeef
00010010: deadbeef
=> run dma
run dma
e0021100: 0f03c405
e0021110: 0005 fff80010 0005 00010010
e0021120:
=> md $dad 5
md $dad 5
0001: 27051956 552d426f 6f742031 2e322e30'..VU-Boot 1.2.0
00010010: deadbeef
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Endianness versus too many byte swaps??
This is probably a Timur question, but any enlightment is appreciated. This concerns Linux-2.6.17.11 from kernel.org with some modifications for our custom 8541 board. The original BSP was evolved from mpc85xx_cds. Down in the guts of arch/ppc/syslib/ppc85xx_seteup.c is a routine called mpc85xx_setup_pci1(). In this routine we do an assignment of some outbound window registers and I am most interested in POTAR2, POWAR2 & POWBAR2 right now. This routine uses a ccsr_pci struct to assign potar2, powar2, powbar2 and others like this: pci->potar2 = 0x0010; pci->powar2 = 0x8004401a; pci->powbar2 = 0x00888000; Where I have changed the constants for our board. The issue is that when I call readl to read back these same registers at the end of this same subroutine, I get into endianess issues. That is, I read back POTAR2 == 0x1000 POWAR2 == 0x1A400480 POWBAR2 == 0x00800800 Where the four bytes in each 32bit word are now exchanged so that 80_04_40_1A became 1A_40_04_80. I understand big versus little endian, that isn't the question. The question is "What is really in the POTAR2, POWAR2 & POWBAR2 registers and how can I prove that what is in the registers is really what I wish to be in the registers?" It may be that one or more endian swap things are going on within Linux and I have inherited some source from others, so actually proving what is in the registers is becoming important. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Endianness versus too many byte swaps??
You do understand that readl is in fact a call to in_le32() on ppc (cf. include/asm-ppc/io.h). The question now is, what endianness you would like in that register? Regards -- Stephane Dear Stephane: Your point is well made. I can see that readl is in fact a call to in_le32. Maybe there is a more basic problem here. If I change the call to readl to a call to in_be32, things make sense again. So, maybe I don't quite understand the endianness setup of this Linux project. I am told that we are running this ppc in big endian, so would this mean that readl & writel should actually be resolving to in_be32/out_be32 respectively? Is there some other setup that may be wrong? Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Endianness versus too many byte swaps??
Thank you Stephane and Kumar. I think the moral of this story is that the drive logic created by my predecessor that calls readl/writel to read/write ppc registers needs to be changed to call in_be32 & outbe32 so I don't continue a mistake. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
DMA take 4
I have gotten to the point where u-boot performs dma transactions repeatedly and reliably with the 8541 and have moved back to my Linux driver. When I complete the DMA transaction in the Linux driver, the SR0 registers tends to have 0x0024 in it, meaning SR0[CH] & SR0[CB] are both set and MR0[CS] is set. I start out with: Set SR0 to 0x_ Set SATR0 to 0x0005_ Set DATR0 to 0x0005_ Set MR0 to 0x0F03_C404 Set SAR0 to the physical address in local memory Set DAR0 to the physical address of the PCI window at 0x8800_ which is been previously setup with POTAR2, POWAR2 & POWBAR2. It seems that the DMA transaction in Linux, using the same 8541 register settings as are in u-boot is not completing. So, this leads me to wondering about ioremap_nocache() perhaps. Although here, I think I want physical addresses for the source and destination of the DMA. What other things can I look into to understand why a DMA in Linux using the 8541 is going awry? Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Exception in kernel mode
I have a PPC8241 which does an Oops: Exception in kernel mode, sig: 4 [#1] PREEMPT NIP: 0900 LR: C00E579C CTR: 3A55 When doing a 'tar -xvzf'. The NIP is pointing at the decrementer interrupt, I believe. As I understand the decrementer, this is basically the timer tick in the ppc and goes off every n ms continuously. A tar is going to be concerned with date/time stamps on files, so it has some interaction with the clock algorithms. It seems to me that the decrementer should be able to go off at any time during kernel operation, so maybe the "Exception in kernel mode" is pointing us in an unusual direction. So, with that said: "What might be the causes of such an exception from the decrementer in a 2.6.17.11 ppc8241 kernel?" "Where should one concentrate ones efforts in figuring this out?" Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Exception in kernel mode
Obviously, you've got an exception in the decrementer exception handler itself -- and this was something like program check exception, judging on the signal you've got (SIGILL). > So, with that said: > "What might be the causes of such an exception from the decrementer in a > 2.6.17.11 ppc8241 kernel?" > "Where should one concentrate ones efforts in figuring this out?" Hrm, looks like some CPU errata maybe... WBR, Sergei Thank you very much for the great hint. I have a follow-up question. I can see from arch/ppc/kernel/head.S that the EXCEPTION_PROLOG macro is the first instruction in the decrementer ISR and it says (amongst other things): mtspr SPRN_SPRG0, r10 mtspr SPRN_SPRG1, r11 Which is, I believe, moving r10 to SPRG0 and r11 to SPRG1. So, how do we know that r10 and r11 are always valid in an interrupt context? Are we setting aside r10 and r11 somewhere else in initialization for this purpose? I have looked at the -ffixed-r2 in the CFLAGS and see it is set aside, but it doesn't appear the build process sets r10 & r11 aside for the exclusive use of interrupt routines. Is there a shadow register set in the 8241 I havent appreciated yet? I have to admit that I am only modestly familiar with the ppc family but would appreciate any insight to understand how this interrupt code works. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Exception in kernel mode
> mtspr SPRN_SPRG0, r10 > mtspr SPRN_SPRG1, r11 > Which is, I believe, moving r10 to SPRG0 and r11 to SPRG1. > So, how do we know that r10 and r11 are always valid in an interrupt > context? Are we setting aside r10 and r11 somewhere else in That doesn't matter to kernel at all -- they are just *saved* in SPRG regs to avoid being trashed by the exception handler. WBR, Sergei Well, unfortunately, now I am more confused. The original Oops was at an NIP of 0900, which I think means it faulted on the first mtspr from r10. I suppose one could argue that pipeline issues might make it fault on the second one and appear to be the first. But, maybe I am confusing myself here. Would I be correct in assuming that some further instruction in the ISR at 0x900 is the culprit? Could there possibly be some user versus supervisor mode thing going on? My key assumption is that the timer_tick (aka Decrementer) has worked for many hundreds of thousands of interrupts and only when running some particular user application, like tar is there a side effect from either a mode or some register value, race condition, or other. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Exception in kernel mode
Can you post the oops that you are seeing, what you need to find out
is what instruction image that is causing the illegal instruction
exception. Once you have that it will be easier to figure out what's
going on.
- k
Dear Kumar:
Here is the Oops, and thank you for looking at this. Things have come to
a halt here until I can figure this one out as about 6 engineers are
going "We cannot use an unreliable 2.6 kernel, fix it immediately, Mr.
Kernel Guy".
Basically, what was happening was a 'tar -xvzf' was underway whose
source was an nfs mount (root = /dev/nfs) and whose destination was
formatted NAND flash (flash_eraseall -q -j /dev/mtd3, then mounted with
'mount -t jffs2 /dev/mtdblockx /mnt/mtdblockx').
Since I sent the last exchange, I see in the kernel source something
about ALTIVEC??. It isnt possible that ALTIVEC needs to be defined for
the 8241 is it?
Charles
rootfs/sbin/fsck.ext3
Oops: Exception in kernel mode, sig: 4 [#1]
PREEMPT
NIP: 0900 LR: C00E579C CTR: 3A55
REGS: c37f3b00 TRAP: 0700 Not tainted (2.6.17.11)
MSR: 00081000 CR: 24022484 XER:
TASK = c3eaf810[940] 'tar' THREAD: c37f2000
GPR00: 3FFF C37F3BB0 C3EAF810 C40216BC FFFE C4022D64
8000
GPR08: C4000A74 C40316BC C4000980 C40216BC C400 10045C90 C37F3CE0
C01D3B68
GPR16: C3ECC5A0 C37F3C50 2200 C2A9E000 C200
1000
GPR24: C01D C200 C37F3C58 0002
C400
Call Trace:
[C37F3BB0] [C00E5764] (unreliable)
[C37F3BD0] [C00C93C4]
[C37F3BF0] [C00B988C]
[C37F3C40] [C00C0644]
[C37F3C90] [C00BBA94]
[C37F3CD0] [C003B8A8]
[C37F3D90] [C003C270]
[C37F3E20] [C003C320]
[C37F3EC0] [C003C470]
[C37F3EF0] [C0055F80]
[C37F3F10] [C00560C0]
[C37F3F40] [C00041A0]
Instruction dump:
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Exception in kernel mode
I ran a couple of more tests and the system did not Oops in the timer_interupt except for the first test this morning. The last two times, the NIP was Oops: Exception in kernel mode, sig: 4 [#1] PREEMPT NIP: C002CE68 LR: C002CEC8 CTR: 3B25 REGS: c3119a00 TRAP: 0700 Not tainted (2.6.17.11) MSR: 00081032 CR: 88022484 XER: TASK = c3ecd870[920] 'tar' THREAD: c3118000 And Oops: Exception in kernel mode, sig: 4 [#1] PREEMPT NIP: C00DEE18 LR: C00DEDD8 CTR: REGS: c299dbc0 TRAP: 0700 Not tainted (2.6.17.11) MSR: 00081032 CR: 84022488 XER: 2000 TASK = c3e2b7d0[925] 'tar' THREAD: c299c000 For comparision, this is the original one from this morning Oops: Exception in kernel mode, sig: 4 [#1] PREEMPT NIP: 0900 LR: C00E579C CTR: 3A55 REGS: c37f3b00 TRAP: 0700 Not tainted (2.6.17.11) MSR: 00081000 CR: 24022484 XER: TASK = c3eaf810[940] 'tar' THREAD: c37f2000 I have to conclude this is not necessarily a timer_interrupt problem. Also, commenting out the innards of the timer_interrupt causes the kernel to hang in its boot right after the message Memory: xxxK available So a properly functioning timer_interrupt is essential to the the kernel booting. But, ... At this point, I really don't know which way to jump. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Exception in kernel mode
It this a system you are just bringing up or one that's been running for a while. It really seems like memory corruption of some form. I'd suggest checking memory controller settings. Also, what happens if you disassemble the kernel image and look at the addresses pointed to by NIP: C00DEE18 & C002CE68. - k Dear Kumar: We have two systems. One based on an 8241, and one based on an 8541. The 8241 has been running for some time with Linux 2.4 and the 8541 is coming up. Both are using the 2.6.17.11 kernel from kernel.org with modifications for our hardware. In the case of the 8241, I started out with the 2.4 modifications, which were originally based on the 8260 and ported them to 2.6. In the case of the 8541, I started out with the embedded planet 8555EP 2.6 kernel source and added that to the 2.6. I dont see this exception in the 8541, although extensive testing has not yet been completed. The 8241 exhibits this exception on three different 8241 boards, so I dont suspect the hardware. We are using the Montavista toolchain and their root filesystem including 'tar' and 'cp' which are the programs that currently exhibit the fault. Yesterday, when I saw an NIP at 0x900, I was ready to jump on the interrupts not being setup correctly, but after a few hours of going through that, I am now convinced the interrupts are setup correctly, so it is something more subtle. Certainly, memory corruption is the next thing to be concerned with. One thing that has concerned me a bit is that we have no swap space available at all. This is an embedded system with 64MByte of RAM and JFFS2 NAND flash with no swap partitions. I suspect auditing the MMU setup differences between the original 2.4 kernel and the new 2.6 kernel for the 8241 board is the next step. The three exceptions I saw yesterday were 1)0x900 in the timer_interrupt, 2) C00DEE18 (inside the tar program) and 3) C002CE68 (in one of the kernel routines). I suspect the actual addresses are red-herrings and this exception can occur at any address. This certainly would tend to indicate some sort of memory setup issue. Changing the Oops logic to printout the NextInstruction as well as the NIP might be helpful so I could discern the difference between what the program is trying to do and what it is really doing. Are there any other thoughts you might have on diagnosis techniques at this point? Charles In the meantime, any thoughts you might have on methods to di ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Exception in kernel mode
#2 is inside the kernel as well. Look at the System.map or objdump - d vmlinux to see what exactly is at those instructions. > I suspect the actual addresses are red-herrings and this exception > can occur at any address. This certainly would tend to indicate > some sort of memory setup issue. I think it's useful to know if the instructions at the two offsets C00DEE18 & C002CE68 are similar in some way before jumping to that conclusion. > Changing the Oops logic to printout the NextInstruction as well as > the NIP might be helpful so I could discern the difference between > what the program is trying to do and what it is really doing. > > Are there any other thoughts you might have on diagnosis techniques > at this point? Try turning on KALLSYMS, this should provide more info on the oops as well. - k Dear Kumar: As always, your advice is appreciated. I will try turning on CONFIG_KALLSYMS in the .config file and see if additional info is obtained. Also, I will audit the MMU setup and see if I can see anything unusual. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MEN A14C-board
Dear Johan: Hello to you. It has been a while since I have admired your train wheels on comp.os.vxworks. On recent linux kernels with PPC, one usually has to add CONFIG_SERIAL_TEXT_DEBUG to see very early serial output from the kernel. This sets up the serial uart before the console is setup. Another issue on ppc kernels is they usually require a console=ttyS0,115200 on the kernel command line (Assuming you primary serial port is ttyS0). I can get into more details if you wish. Let me know. Charles From: [EMAIL PROTECTED] on behalf of Johan Borkhuis Sent: Fri 3/16/2007 2:28 AM To: linuxppc-embedded@ozlabs.org Subject: MEN A14C-board Hello, I am working on getting Linux running on a MEN-Micro A14C board. This board contains a PPC-8540, and has a U-Boot compatible bootloader. Is anyone else working with this board already? I tried modifying some BSP's, but I am not able to get past the bootloader prompt, the kernel itself does not produce any output. Kind Regards, Johan Borkhuis ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Howto read I2C on MPC5200 Lite
I have an embedded system with a PPC8541 using remote debugging across the serial port. I am using Fedora Core 6 on my host along with gdb 6.3 cross compiled for the ppc target and Linux 2.6.17.11 on the PPC8541 target. I can stop the kernel boot with 'kgdbwait' on the command line, startup gdb or ddd/gdb and set a breakpoint on do_fork which triggers reliably. >From there, I can delete that breakpoint, set a breakpoint further along in >do_fork or continue using ddd to a location further along, but I cannot >execute 'step'. When I execute a cont from either the gdb window or the ddd window, I do see the message: "Can't send signals to this remote system. SIGILL not sent. This problem occurs with or without ddd running the inferior debugger, so I suspect it is a gdb/target issue and not necessarily a ddd issue. Mostly, I am trying to understand what is going on. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
gdb question regarding step vs breakpoint
My apologies for not changing the subject in my gdb email. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
A question regarding step and breakpoints
Gentlemen: I have an embedded system with a PPC8541 using remote debugging across the serial port. I am using Fedora Core 6 on my host along with gdb 6.3 cross compiled for the ppc target and Linux 2.6.17.11 on the PPC8541 target. I can stop the kernel boot with 'kgdbwait' on the command line, startup gdb or ddd/gdb and set a breakpoint on do_fork which triggers reliably. >From there, I can delete that breakpoint, set a breakpoint further along in >do_fork or continue using ddd to a location further along, but I cannot >execute 'step'. When I execute a continue from either the gdb window or the ddd window, I do see the message: "Can't send signals to this remote system. SIGILL not sent. Even with this message, I can still breakpoint, just not step. Some insight would be appreciated. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
STACK & HEAP
Where are the stack and heap initialized in a linux-2.6.17.11 kernel for user space applications after init runs for a PPC8241 architecture? Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: ttyS0 ttyS1
Dear Otto:
You might check that the dev entry points in your root file system for
/dev/tty, /dev/console, /dev/ttyS0 and /dev/ttyS1 all exist. They must be
created with mknod and not with mkdir.
These are the settings you should see with an 'ls' of the target's root
filesystem on the host which has created it. All of these entries should be
character devices as shown by the first bit of the permissions being a 'c'.
/dev/console 5 1
/dev/tty 5 0
/dev/ttyS0 4 64
/dev/ttyS1 4 65
Charles Krinke
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Fri 3/23/2007 3:43 AM
To: linuxppc-embedded@ozlabs.org
Subject: ttyS0 ttyS1
Hello,
i have problems to use ttyS1 on my TQM885 Board.
fd1 = open("/dev/ttyS0",O_RDWR);
fd2 = open("/dev/ttyS1",O_RDWR);
I have expected to get different filehandles, but
both handles for ttyS0 and ttyS1 are 0!
Any help is very appreciated.
_
Dr. Otto Parzhuber
Munich University of Applied Sciences
Fac. of Precision Engineering
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
PPC login puzzle
I have 2 targets, both kernel.org linux-2.6.17.11. Both are currently using rootfile systems from montavista's 2.6.10 distribution. One is a PPC8241 and the other is a PPC8541. On the 8241, I can login with a telnet session as root. On the 8541, I cannot. On both, I can login at the serial terminal as root with no passwd. Neither as a password for root in /etc/passwd. That is, the first line in the passwd file says "root::0:0:root:/root/bin/bash". Being toasters, I dont want a password to cook my toast. The question is: "What are the various things that might cause one toaster to be able to login from a telnet session and another, very similar one to not be able to do this?" Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: PPC login puzzle
From: Bill Gatliff [mailto:[EMAIL PROTECTED] Sent: Fri 3/30/2007 8:53 PM To: Charles Krinke Cc: linuxppc-embedded@ozlabs.org Subject: Re: PPC login puzzle Charles: Charles Krinke wrote: > I have 2 targets, both kernel.org linux-2.6.17.11. Both are currently using > rootfile systems from montavista's 2.6.10 distribution. One is a PPC8241 and > the other is a PPC8541. > > On the 8241, I can login with a telnet session as root. On the 8541, I > cannot. On both, I can login at the serial terminal as root with no passwd. > > Neither as a password for root in /etc/passwd. That is, the first line in the > passwd file says "root::0:0:root:/root/bin/bash". > > Being toasters, I dont want a password to cook my toast. > > The question is: > > "What are the various things that might cause one toaster to be able to login > from a telnet session and another, very similar one to not be able to do > this?" > Are their /etc/securetty files identical? b.g. -- Bill Gatliff [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Yes, that that is another part of the puzzle as both the /etc/securetty and the /etc/xinetd.d/telnet files are identical in both root filesystems. So, there must be some ither file somewhere keeping me from cooking my toast with a telnet login to the 8541. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: PPC login puzzle
Seems to me thing you can do is find out why the telnet session is being
rejected. Have you done an ethernet capture?
Do you have any firewalling setup? In that case you need to make sure your
rules are setup properly. The ethernet capture should give you a clue.
Are you sure the telnetd can be found on your system that doesn't work? What
do the logs tell you on the machine that doesn't work? I think xinetd kicks
out a log file, what does that tell you?
Have you tried on the 8541, login to the terminal and then telnet to
localhost? If you can do that, then I'd say it's a firewalling problem, if
not, then it's a telnetd type of problem.
Hope that helps.
-stv
--
/*
* Steve Iribarne
* Software Engineer
* (aka Grunt)
*/
It is interesting that 'telnet localhost' fails in a similar way as telnet
across the network, and I appreciate your kind hints, especially about the log
file and /var/log/syslog helps a bit on this problem.
When trying to telnet accross the network, syslog says
in.telnetd[]: connect from x.x.x.x
But entering root doesnt work and the host then says:
sff1 login: root
Login incorrect
There are no further errors on the 8541. When trying to 'telnet localhost',
syslog says
in.telnetd[]: connect from 127.0.0.1
But neither completes the login, so although there is a clue here, the logical
path to conclusion is still escaping me a little bit.
I can see that both targets have the same /etc/xinted.d/telnet file and it
contains:
service telnet
{
flags = REUSE
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/in.telnetd
server_args = -h
log_on_failure += USERID
}
which I think is reasonable in this situation. So, this begs the question of
what other things still bear on this type of problem. Again, I appreciate your
taking the time to help me understand a bit more of how this fits together.
Charles
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
DMA Puzzle
My apologies for the complexity of this e-mail but DMA seems to be a complex subject. Thanks to Ed.S a while back, I have DMA working fine from U-Boot, but I am having a problem in Linux with the 8541 processor using the 2.6.17.11 kernel. I need to DMA through an outbound address translation window setup at 0x8800_ and the chip I am DMA'ing to is responding to 64bit DAC (Dual Address Cycles) and its memory is setup beginning at 0x1__. It seems, that the MR0/SR0 indicate the DMA has stalled and I have not figured out why yet. Here is the progression in the DMA driver in Linux First obtain a pointer to my RAM buffer using pci_map_single. This returns the buffer in kernel space at 0xC768_ (or thereabouts) to 0x0768 and prepare to transfer 0x1 (64K bytes) from 0x0_c768 to 0x1__. This is the first of several printk's in the DMA driver where the POTAR2 is being used to hold the hi part of the 64bit address. a src_low_addr:0768 winBase: POTAR2:0010 newLowAddr:0768 dir:1 size:0001 Next we write all f's to SR0 to clear it and here is the next printk. z MR0: SR0: begin Now we write the low part of the source address to LSAR0. A constant value of 0x5 to DATR0. The size in bytes to the BCR (Byte Count Register) is next Then set the MR0 to 0x0f03c404 indicating a)disable bandwidth sharing, DAHTS & SAHTS both 8 bytes, SRW set & CDSM/SWSM cleared to indicate start the DMA by writing the destination. Lastly, we write the destination to the DAR0 register. At this point, the next printk has a problem. The MR0 register has its CS bit set and the SR0 register has its CB bit set. This indicates to me that the channel is busy, it stalled and cannot continue. c MR0:0F03C405 SR0:0004 SATR:0005 DATR:0005 dst_low_addr:0 Just for reference, here are two final printk's with some of the other pertinent registers. d POTAR2:0010 LSAR0:0769 DAR0:8801 BCR:0 DGSR: e POTEAR2: POWBAR2:00088000 POWAR 0:80044019 1:8004401A 2:8004401B So, the question becomes, "What is going awry here and where should I be looking in order to understand how to close the DMA loop back to Linux?". Charles Krinke ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
gdb & kgdb in MPC85xx
I have a question relating to stepping with gdb connected to a remote target. I can connect to the target with its ttyS1 and 'list', 'break' just fine. This is with a Linux-2.6.17.11 kernel and gdb 6.5. A 'cont' begets a message, and a step fails to return. I am hoping someone can offer a suggestion or two. As an example, I start from uboot with the kernel command line containing 'kgdbwait kgdb=ttyS1,115200' and the target stops at 'setup_arch: kgdb breakpoint' as I would expect. I am using a USB serial dongle, which has worked well for this type of debugging on other targets. $ .../linux $ ppc-gdb vmlinux [its version 6.5 cross from ultsol] (gdb) show architeture [its powerpc:common] (gdb) show verbose [its on] (gdb) target remote /dev/ttyUSB0 (gdb) list [works fine] (gdb) break do_fork [sets fine] (gdb) cont [some problem here as gdb says "Can't send signals to this remote system. SIGILL not sent." but the breakpoint is taken and the target stops at the beginning of do_fork] (gdb) step [big problem now as the step never returns] Charles Krinke ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
IRQ questions & puzzles
I have a linux-2.6.17.11 source tree that has configs for two boards. One has an 8241 and the other has an 8541. The kernel code works fine on the 8241, but appears to lock up in my custom driver in the 8541 when interrupts are enabled. What I see happening, based on using a BDI to go/halt after the apparent lockup is that the kernel is spinning around in routines like kernel/irq/handle.c:__do_IRQ and an associated arch/powerpc/kernel/irq.c. It looks like the interrupt, which should be level triggered and at this point, is probably continuously asserted is causing the kernel to spin in a tight loop and be incapable of doing printk's out the serial port at 115200. This leads to a few questions: 1. I can see most everything comes from arch/ppc, but do_IRQ comes from arch/powerpc. Is that OK? 2. What is the most straightforward way to slow down a tight loop like this slow enough so I can printk what is happening. 3. What might be the likely scenarios leading to such a despicable state. Charles Krinke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: IRQ questions & puzzles
Maybe I need to answer part of my question and ask another. I can see, by putting a printk into ../kernel/irq/handle.c:__do_IRQ that I normally get 3 interrupts with this 8541 board based on a linux-2.6.17.11 kernel. A cat /proc/interrupts shows enet_rx on interrupt 93, enet_tx on interrupt 94 and the serial port in interrupt 106. I have a peripheral that sets irq to 16 and does a request_irq and this works in the 8541 board. But on the 8541 board, the printk from inside __do_IRQ shows the irq variable is zero, not 16. Can someone please help me understand the care and feeding of external interrupts in the 8541 a bit more completely? Charles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Krinke Sent: Thursday, April 26, 2007 11:36 AM To: linuxppc-embedded@ozlabs.org Cc: Randy Brown; Chris Carlson; Kevin Smith Subject: IRQ questions & puzzles I have a linux-2.6.17.11 source tree that has configs for two boards. One has an 8241 and the other has an 8541. The kernel code works fine on the 8241, but appears to lock up in my custom driver in the 8541 when interrupts are enabled. What I see happening, based on using a BDI to go/halt after the apparent lockup is that the kernel is spinning around in routines like kernel/irq/handle.c:__do_IRQ and an associated arch/powerpc/kernel/irq.c. It looks like the interrupt, which should be level triggered and at this point, is probably continuously asserted is causing the kernel to spin in a tight loop and be incapable of doing printk's out the serial port at 115200. This leads to a few questions: 1. I can see most everything comes from arch/ppc, but do_IRQ comes from arch/powerpc. Is that OK? 2. What is the most straightforward way to slow down a tight loop like this slow enough so I can printk what is happening. 3. What might be the likely scenarios leading to such a despicable state. Charles Krinke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
How do external irq's get mapped?
Let me try a more simplified IRQ question a different way by only referring to the 8541. There are 12 external interrupt sources, irq[0..11] and as I understand it, they all go through one vector, ExternalInput set in head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...). I am striving to understand how mapping of these external pins irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts". Could someone point me at some references I can read to understand this nuance of the 8541 in a linux-2.6.17.11 kernel, please. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: How do external irq's get mapped?
-Original Message- From: Sergei Shtylyov [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 10:04 AM To: Charles Krinke Cc: Jon Loeliger; Randy Brown; Chris Carlson; Kevin Smith; linuxppc-embedded@ozlabs.org Subject: Re: How do external irq's get mapped? Hello. Charles Krinke wrote: > Let me try a more simplified IRQ question a different way by only > referring to the 8541. > There are 12 external interrupt sources, irq[0..11] and as I understand > it, they all go through one vector, ExternalInput set in > head_fsl_booke.S and this vector resolves to "do_IRQ()", which I believe > is in arch/powerpc/kernel/irq.c (not arch/ppc/kernel/...). > I am striving to understand how mapping of these external pins > irq[0..11] gets to IRQ numbers as shown with "cat /proc/interrupts". IIUC, the external IRQ #'s should follow those occupied by 32 internal IRQs. But those shown in that file are "virtual" numbers, i.e. they got re-mapped by the kernel as it sees fit (basically, it tries to assign the same # to IRQs above 15 and remaps those below) > Could someone point me at some references I can read to understand this > nuance of the 8541 in a linux-2.6.17.11 kernel, please. I'm not sure arch/powerpc/ in 2.6.17 had the complete MPC8541 support... WBR, Sergei So would this mean that the external IRQ0 pin would map to irq #32 and not irq #16 and the external IRQ11 pin would map to irq #43 and not irq #27? So that if I want IRQ0, I would set my irq member of the pci_dev struct to 32? Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: How do external irq's get mapped?
As I understand it, the 8541 and 8555 have 12 external IRQ[0..11], 21 internal interrupts, and 4 messaging interrupts. In looking at the MPC8555ERM.pdf file, which is my main resource, it looks like the internal interrupt numbers for the 1st TSEC are 19 for transmit and 20 for receive. A 'cat /proc/interrupts' shows the 1st TSEC transmit as 93 and the receive as 94, so I am puzzled how we get from 19 to 93 for the transmit and from 20 to 94 for the receive. Perhaps understanding this will help me figure out what number to put into the pci_dev structure for external IRQ0. At this particular moment, I can put 16, 32 or other numbers into the pci_dev and do a request_irq for my driver in Linux-2.6.17.11. The driver interrupts are enabled, but when "__do_IRQ" executes, its irq variable is zero, which it should not be. I can also see with a printk in this same "__do_IRQ" that the TSEC tx is indeed 93, the TSEC rx is indeed 94 and the uart is 106. Sorry to be a bit dense here, but understanding this is important to moving forward. Charles Krinke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: How do external irq's get mapped?
> transmit and 20 for receive. > A 'cat /proc/interrupts' shows the 1st TSEC transmit as 93 and the > receive as 94, so I am puzzled how we get from 19 to 93 for the transmit > and from 20 to 94 for the receive. Perhaps understanding this will help I'd suspect you also have CPM on this SoC (or have CONFIG_CPM* wrongly enabled?). > me figure out what number to put into the pci_dev structure for external > IRQ0. Could you post your /proc/interrupts? > Charles Krinke WBR, Sergei Dear Sergei: Here is the result of /proc/interrupts [EMAIL PROTECTED]:~# cat /proc/interrupts CPU0 2: 0 i8259 Edge 82c59 secondary cascade 32: 0 CPM2 SIU Level ichar 93: 10701 OpenPIC Level enet_tx 94: 13945 OpenPIC Level enet_rx 98: 0 OpenPIC Level enet_error 106:542 OpenPIC Level serial 107: 0 OpenPIC Level i2c-mpc 110: 0 OpenPIC Level cpm2_cascade 128: 0 OpenPIC Level BAD: 0 [EMAIL PROTECTED]:~# The current issue is understanding how enet_tx, enet_rx & serial get to be 93, 94 & 106 respectively. Once I understand that, I may have a clue how to deal the one labelled ichar, which is the one that doesn't quite work. This is a PCI chip our company designed. Charles Krinke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: How do external irq's get mapped?
A little further on IRQ mapping. I was incorrect in saying enet_tx is at 19. According to MPC8555ERM.pdf the TSEC1_tx, TSEC_rx and DUART are at 13 TSEC1_tx (maps to 93) 14 TSEC1_rx (maps to 94) 26 DUART (maps to 106) A 'cat /proc/interrupts' shows this 93, 94 & 106 mapping: [EMAIL PROTECTED]:~# cat /proc/interrupts CPU0 2: 0 i8259 Edge 82c59 secondary cascade 32: 0 CPM2 SIU Level ichar 93: 10701 OpenPIC Level enet_tx 94: 13945 OpenPIC Level enet_rx 98: 0 OpenPIC Level enet_error 106:542 OpenPIC Level serial 107: 0 OpenPIC Level i2c-mpc 110: 0 OpenPIC Level cpm2_cascade 128: 0 OpenPIC Level BAD: 0 [EMAIL PROTECTED]:~# Looking at arch/ppc/platforms/85xx/mpc85xx_cds_common.c, I can see the mpc85xx_cds_openpic[] array and since CONFIG_PCI is defined, the first four entries for IRQ0..3 (or INTA, INTB, INTC & INTD) have non-zero entries containing (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), which should be OK. Down a little further in this file is mpc85xx_cds_init_IRQ and it we do not have CONFIG_MPC8548 defined, so we should be calling openpic_set_sources(0, 32, OpenPIC_ADDR + 0x10200) followed by calling openpic_set_sources(48, 12, OpenPIC_ADDR + 0x1) This leads to a couple of new questions. 1. We have no 8259 in our design. Is this a concern as we are always calling the i8259_init() routine. 2. The 'cat /proc/interrupts' shows 82c59 secondary cascade. Again, does this matter? 3. The offset between TSEC1_tx of 13-->93 is a constant of 80 decimal. Is this a clue to what the irq should be set to for external IRQ0 in this design? Charles Krinke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: How do external irq's get mapped?
> 3. The offset between TSEC1_tx of 13-->93 is a constant of 80 decimal. > Is this a clue to what the irq should be set to for external IRQ0 in > this design? Yeah. 112. However, you really should switch to using arch/powerpc, and device trees. In that instance, you set the irq to the pin number (1-4), and the kernel will map that based on the interrupt-map property of the pci node. It was for precisely this type of problem that the irq numbers were virtualized. The IRQ numbers in arch/ppc actually change depending on whether you've *configured* the CPM or not. Andy Dear Andy: I appreciate your kind advice, it does help converge understanding somewhat. I can see how we get the 80 decimal offset with 64 + 32. I have commented out the call i8259_init(0,0) in arch/ppc/platforms/85xx/mpc85xx_cds_common.c, but retained the call to cpm2_init_IRQ(); shortly after that. We are constrained to finish the current project with the kernel we started with, so changing from ppc to powerpc is really difficult right now. When the pci_dev->irq member is set to 112, there is a difference in behavior. Now open_pic.c:720 is complaining that 112 is "invalid irq 112", so some additional understanding is needed on my part. If you get a chance to help me continue to understand how the 8541 interrupts are sutured into Linux, it would be greatly appreciated. Charles Krinke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: How do external irq's get mapped?
At this point, I would just like to confirm I am thinking clearly and
now understand the IRQ mapping. We are constrained to finish this
project with the kernel we started with, linux-2.6.17.11, so this
discussion is centered around that code base. This is my understanding
based on last week's e-mails and my research.
1. In arch/ppc/platforms/85xx/mpc85xx_cds_common.c is the
mpc85xx_cds_openpic_initsenses[] whose first 4 members are set to
IRQ_SENSE_LEVEL or'ed with IRQ_POLARITY_NEGATIVE. This means the first
four external interrupts are enabled and neg polarity. I can use these
entries as is and change the others from 0x0 as I need more of the
external interrupt pins.
Just for reference, here are a few lines from mpc85xx_cds_init_IRQ
mpc85xx_cds_init_IRQ(void)
{
openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
/* Map PIC IRQs 0-11 */
openpic_set_sources(48, 12, OpenPIC_Addr + 0x1);
#if 0
openpic_hookup_cascade(PIRQ0A, "82c59 cascade", i8259_irq);
i8259_init(0, 0);
#endif
/* Setup CPM2 PIC */
cpm2_init_IRQ();
setup_irq(MPC85xx_IRQ_CPM, &cpm2_irqaction);
2. In this routine, the first openpic_set_source call is for the 32
internal IRQ's and the second openpic_set_sources maps the 12 external
IRQ's beginning at 48, so that means my external IRQ mapping is:
ExtIrQLinuxIrqNum
0 48 (first four are enabled)
1 49
2 50
3 51
4 52 (last 8 not enabled by default)
5 53
6 54
7 55
8 56
9 57
10 58
11 59
Is this correct?
Charles
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
I2C support for 8541
Assuming I have the external IRQ's understood, the next issue is the hardware clock on our board with the linux-2.6.17.11 kernel. We are using a "DS1338U", which is an I2C RTC. I am trying to identify the relevant source for the 8541/8555 I2C interface in the source base which reads/writes I2MOD, I2ADD, II2BRG, I2COM, I2CER & I2CMR. I can find a few references to MPC85xx_CPM_I2C in ../syslib/mpc85xx_devices.c, but nothing close in drivers/i2c/... Can someone help me understand the completeness of the I2C source in the 2.6.17.11 kernel, please. Charles Krinke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: How do external irq's get mapped?
Please pardon the top post, it is done to help my local compatriots read
more easily.
Andy, our MPC85xx_OPENPIC_IRQ_OFFSET is 80, but the call to
openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET) occurs after the two calls to
openpic_set_sources. This leads me to believe that the mapping goes
Internal irqs are 00..31 based on first openpic_set_sources(0, 32, ..)
External irqs are 48..60 based on second openpic_set_sources(48, 12,
...)
Then we have the openpic_init(80) call.
So, I though the external IRQ0 was mapped to 48. But is it really mapped
to 80 + 32 or 112 instead. If that is the case, there is another
problem.
The new problem is that if I set the irq to 112, when it is insmodded, I
get an error from open_pic.c of the form:
Open_pic.c:720 invalid irq 112
This seems to be coming from the macro at line 144 in open_pic.c
#define check_arg_irq(irq) \
if (irq < open_pic_irq_offset || irq >=
NumSources+open_pic_irq_offset \
|| ISR[irq - open_pic_irq_offset] == 0) { \
printk("open_pic.c:%d: invalid irq %d\n", __LINE__, irq); \
dump_stack(); }
Charles
-Original Message-
From: Andy Fleming [mailto:[EMAIL PROTECTED]
Sent: Monday, April 30, 2007 5:23 PM
To: Charles Krinke
Cc: Sergei Shtylyov; Randy Brown; Chris Carlson; Kevin Smith;
linuxppc-embedded@ozlabs.org
Subject: Re: How do external irq's get mapped?
On Apr 30, 2007, at 09:32, Charles Krinke wrote:
>
>
> At this point, I would just like to confirm I am thinking clearly and
> now understand the IRQ mapping. We are constrained to finish this
> project with the kernel we started with, linux-2.6.17.11, so this
> discussion is centered around that code base. This is my understanding
> based on last week's e-mails and my research.
>
> 1. In arch/ppc/platforms/85xx/mpc85xx_cds_common.c is the
> mpc85xx_cds_openpic_initsenses[] whose first 4 members are set to
> IRQ_SENSE_LEVEL or'ed with IRQ_POLARITY_NEGATIVE. This means the first
> four external interrupts are enabled and neg polarity. I can use these
> entries as is and change the others from 0x0 as I need more of the
> external interrupt pins.
>
> Just for reference, here are a few lines from mpc85xx_cds_init_IRQ
>
> mpc85xx_cds_init_IRQ(void)
> {
> openpic_set_sources(0, 32, OpenPIC_Addr + 0x10200);
> /* Map PIC IRQs 0-11 */
> openpic_set_sources(48, 12, OpenPIC_Addr + 0x1);
This line is almost more important:
openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET);
You need to find out what that is defined to be. My tree says it's
defined as CPM_IRQ_OFFSET + NR_CPM_INTS (or 0, if CONFIG_CPM2 isn't
defined).
So that's the 80, if NR_8259_INTS is 16. Otherwise it's 64. So 112
could work, but if you have your config different, the numbers will
move.
>
> 2. In this routine, the first openpic_set_source call is for the 32
> internal IRQ's and the second openpic_set_sources maps the 12 external
> IRQ's beginning at 48, so that means my external IRQ mapping is:
>
> ExtIrQLinuxIrqNum
> 0 48 (first four are enabled)
> 1 49
> 2 50
> 3 51
> 4 52 (last 8 not enabled by default)
> 5 53
> 6 54
> 7 55
> 8 56
> 9 57
> 1058
> 1159
>
> Is this correct?
Depends on your configuration. But probably not. The CPM takes up
some space, too.
Andy
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: How do external irq's get mapped?
> The new problem is that if I set the irq to 112, when it is
> insmodded, I
> get an error from open_pic.c of the form:
>
> Open_pic.c:720 invalid irq 112
>
> This seems to be coming from the macro at line 144 in open_pic.c
>
> #define check_arg_irq(irq) \
> if (irq < open_pic_irq_offset || irq >=
> NumSources+open_pic_irq_offset \
> || ISR[irq - open_pic_irq_offset] == 0) { \
> printk("open_pic.c:%d: invalid irq %d\n", __LINE__, irq); \
> dump_stack(); }
Any chance you can identify:
1) Where this macro is being called from when it fails
2) Which of the 3 conditions above are actually true
Andy
Dear Andy:
In our system, open_pic_irq_offset=80, numSources=60, *but* ISR[irq -
open_pic_irq_offset]=NULL when irq 112 is enabled.
It looks to me like each call to openpic_set_sources inits ISR[]
elements according to the first two arguments. We have two calls to
openpic_set_sources.
Internal irqs 00..31, 1st openpic_set_sources(0, 32) -- ISR[0..32]
External irqs 48..60, 2nd openpic_set_sources(48, 12) -- ISR[48..60]
But ISR[112] is never initialized in the source base.
I tried the cheap shot of adding a third openpic_set_sources(112, 12),
but I suspect the real answer is a bit more complicated then that.
Again, I thank you for your kind words while I struggle through this
external interrupt initalization for the PPC8541 in the Linux-2.6.17.11
kernel.
Charles Krinke
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: How do external irq's get mapped?
Dear Andy: I want to thank you and your group for getting us off the externalIRQ block. Using irq = 128 allows the external device to interrupt on IRQ0 to the 8541. I know it was a long, drawn-out explanation, but the help in understanding is much appreciated. Charles Krinke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: zImage.elf loads but does not start
I find this usually happens when /dev/tty, /dev/console or /dev/ttyS0 are not setup properly. That is, they are files instead of nodes. This menas you have mounted the root filesystem and init is running on that root filesystem. Charles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Craine Sent: Tuesday, May 08, 2007 2:50 PM To: Leonid Cc: linuxppc-embedded@ozlabs.org; Mirek23 Subject: Re: zImage.elf loads but does not start Leonid wrote: > rootpath= > [9.130834] Looking up port of RPC 13/2 on 129.129.130.106 > [9.207363] Looking up port of RPC 15/1 on 129.129.130.106 > [9.303794] VFS: Mounted root (nfs filesystem). > [9.359316] Freeing unused kernel memory: 96k init > [9.422162] Warning: unable to open an initial console. > > The exact device node this requires is /dev/console c 5 1 That should solve your issue. Cheers, Adrian. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Accessing 8541 registers from user space
I have a need to be able to read and write the gpio data registers PDATC and PDATD from a user space program. We have a userspace program that succesfully mmaps an offset in /dev/mem and reads/writes registers in a CPLD at 0xFF00_. The issue seems to be that when I mmap /dev/mem to 0xE000_0D50 to read the PDATC register, Linux-2.6.17.11 just locks up. Can anyone shed a little light on why this could be happening? Charles Krinke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Advice needed
I'm having a little trouble with memory mapped registers in both a NAND chip and a CPLD on an 8541 design where the kernel is based on linux-2.6.17.11 and mpc85xx_cds_common. The NAND and CPLD are obviously not part of the memory map of the mpc85xx_cds_common, and in our case are at local memory addresses NAND=0xFF008000, 32K and CPLD=0xFF00, 32K. Both need to be mapped into memory in Linux. I am looking at arch/ppc/platforms/85xx/mpc85xx_cds_common.c around platform_init. I wonder if a Freescale person could give me an opinion of where the appropriate place is to call settlbcam to allow access to these two 32K memory regions? Charles Krinke ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
sys_futex
This is a user space application to kernel interface question. We are using linux-2.6.17.11 in our design and have two boards. One 8241 and one 8541. In user space, we need to use the system call "sys_futex", but when the user space application is compiled we have an unresolved linkage error. Can someone offer a suggestion on the care and feeding of "sys_futex" in a ppc 8241/8541 environment. Thanks. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
I2C interrupts on 8541
I'm puzzled about how to setup interrupts for the second I2C interface in an 8541. This is the CPM interface, the one with buffer descriptors. I see mention of its I2CER/I2CMR registers, but am having trouble figuring out how to enable and interrupt so that when the interface is in slave mode and a packet is received, it will vector to an interrupt service routine. I am using Linux-2.7.17.11 and I know you-all have gone past this a bit, but in the midst of a project, we are constrained to finish with the kernel we started with. A few pointers on enabling an interrupt from this interface would be greatly appreciated. Charles ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
