Kernel start error
Hi all.
I'am coming to you looking for some experience with HydraXC-50
(Virtex4FX12, Proc PPC405) to try to figure out some boot sequence
error.
On that platform there is an Atmega8L that load FPGA bitstream through
JTAG chain. The Loader V1.1 code is in FPGA internal BRAM so that after
FPGA initialisation the PPC405 start execution from that memory.
This loader start properly, read the kernel image.bin from SDCARD and
try to start the kernel at is start address, in my case 0x40.
In the loader the last point is
print("\n\rStarting image from Memory\n\r");
jump();
with jump function
void jump() {
cmdline[0]='\0';
xil_printf("mem_start %08X\r\n",mem_start);
kernel_start = (void_fn)mem_start;
kernel_start(cmdline);
}
The loader hangs up after the messages :
Starting image from Memory
mem_start 0040
If I download the kernel image (zImage.elf) using JTAG emulator under
Xilinx XMD shell, with commands
dow zImage.elf
con
then the kernel start properly.
I did not succeed to understand why the loader start procedure hangs up.
Thank in advance for any help.
Chris
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: New Bestcomm/FEC patches (was: Re: [PATCH 0/7] MPC5200 and Lite5200b low power modes)
On 01/03/07 15:51 +0100, Bartlomiej Sieka wrote: > Grant Likely wrote: > > On 3/1/07, Domen Puncer <[EMAIL PROTECTED]> wrote: > >> Hi! > >> > >> Patches are based on latest mainline git tree + fec patches: > >> Fec_MPC5200_eth_driver.patch > >> Copy_bestcomm_support_files_into_arch_powerpc.patch > >> Make_FEC_work_on_the_lite5200.patch > >> > > ---8<---snip--->8--- > >> I would appreaciate any comments, suggestions etc. > > > > Cool, good work. I'll try to do a proper review today. > > > > Note on the Bestcomm stuff; the patches that you've referenced above > > will not be going into mainline. They will be replaced by a new set > > of bestcomm/FEC patches, hopfully in the .22 timeframe, so your > > patches there will need some rework. > > Hello, > > I am working on porting arch/powerpc Linux to a custom MPC5200B-based > board, and currently using your 52xx-dev branch. Is this new set of > bestcomm/FEC patches already in any of your publicly available branches, > or is it something completely fresh? I am seeing some networking > problems, and would be interested in giving new patches a try. Patches I used were from Grant's 52xx-dev branch. Domen > > Regards, > Bartlomiej > > > > ___ > 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: MPC5200, PLX9054 PCI Card - stalled DMA transfers
Oliver Rutsch wrote: > Hi, > > we're using a TQM5200S-Module (MPC5200) on a STK52xx-board with a > PLX9054-based PCI card. The 2.4.25-kernel on the 3.1.1 ELDK had big > problems to map the PCI resources of this card, so I tried the latest > 2.6.19.2-kernel of the 4.1 ELDK. This kernel mapped successfully the PCI > resources on this card. > After building the latest PLX driver on the 2.6.19-kernel (I had to make > some changes for the .19 kernel and for some litte/big endian issues) I > was able to transfer data with programmed I/O. But as this is too slow I > like to use the DMA functions of this device and here is the problem: > PLX provides an example program for scatter/gather DMA. This program > works with their latetst driver on a linux PC. But on the TQM5200 the > 'Channel 0 done' flag of the DMASR0 register is never set after starting > the DMA transfer. What can be the reason for this? The debug output of > the driver looks O.K., but waiting for the DMA done interrupt gives a > timeout, because the flag is not set. I wrote some test patterns in my > DMA buffer before the DMA transfer and no byte of the buffer was > altered, so the DMA engine seems not to be able to write a single byte. > Has anybody this or a similar card running on a ppc environment? Any > ideas what I can do? > > Thanks in advance and bye, Hi, I use the PLX-9054 in my custom boards (TI DSP on-board), and Linux x86 host computer. When debugging, I load a simple memmap driver, and 'tickle' the board registers directly. There's a copy of the PLX driver in here ... http://www.ovro.caltech.edu/~dwh/correlator/pdf/cobra_driver.pdf http://www.ovro.caltech.edu/~dwh/correlator/software/cobra_driver-2.9.tar.gz And if my memory serves me right, I think I wrote a generic one that lets you map any PCI device ... http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-723-Hawkins.pdf http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz Anyway, manually setup a DMA transfer and convince yourself that you know which bits to twiddle, then figure out why the driver code isn't doing as its asked. Take a look at the COBRA driver code, it has PLX-9054 DMA control. There might be a few clues in my docs that'll help you. Cheers Dave ___ 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
Re: Kernel support for the TI1520 PCI-CardBus bridge?
Hi Frank, [EMAIL PROTECTED] wrote on 03/01/2007 02:01:19 AM: > On Thursday 01 March 2007 02:35, [EMAIL PROTECTED] wrote: > > Hi all, > > > > We're designing a new product and we want to put a CF card in it. We're > > I got a TI cardbus controller PCI1520IPDV working in a embedded PPC > system with little modifications to kernel 2.4.25, but i didn't > found a common > configuration for the I/O-space that works for all type of cards > (cardbus and > pcmcia). I tested some pcmcia cards, like WLAN, Ethernet, pcmcia harddisk > and CF-Adapter with a different kernel configuration as for cardbus cards. > > Frank > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded Thanks for the reply. So it sounds like if you got it working in 2.4.25, there's probably better support in the current kernel. How much work did you have to do? You say 'little modifications'. Was it a few hours, days, or weeks? Based on what I've found so far (and my admittedly naive understanding of pcmcia and the kernel), it looks like this should almost be plug and play. Turn on the the yenta pcmcia driver and tell it to look for TI parts. The TI1520 is alredy listed in pci_ids.h so it may be that it'll just work. We're just looking for a warm fuzzy before we commit to this part since we're getting no help from TI on it. And if we can't find a warm fuzzy will look at something else. Thanks again. Take care and stay safe. bruce ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
PowerPC Switches Extension for the Eclipse CDT released on alphaWorks
A PowerPC Switches Extension for the Eclipse CDT is now available here: http://alphaworks.ibm.com/tech/powerpcswitches This plug-in provides PowerPC-specific tool settings for the GNU C/C++ compiler and assembler, as well as link options (also supplied to gcc), for managed C and C++ projects. It is free to download and released under an IBM license which allows unlimited use and copying. Please read the license for details. If you have any feedback on this plug-in, please provide it through the forums tab at the link above. Regards, - Corey -- Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 [EMAIL PROTECTED] -- Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kernel support for the TI1520 PCI-CardBus bridge?
Ben, Ben Warren <[EMAIL PROTECTED]> wrote on 03/01/2007 04:00:27 AM: > Bruce, > --- [EMAIL PROTECTED] wrote: > > > Hi all, > > > > We're designing a new product and we want to put a > > CF card in it. We're > > If you don't need hot-plugging and happen to be using > either a Freescale PowerQUICCx or IBM/AMCC 4xx chip, > you might consider connecting directly to the local > bus and operating in TrueIDE mode. This has > limitations, but has been done many times. > > regards, > Ben Thanks for the feedback. We've considered doing that. We're using a MPC8347 and have FS's 8349ITX ref design which is where we got the idea of using the local bus. But digging into our requirements more we found that we want to support Compact Flash + cards in addition to Compact Flash Storage cards. Also, in the future, we'll probably want to support more than one card at a time. That's why we decided a PCI-CF bridge with two slots would be a better solution. A related question (since I'm new to this PCMCIA/CardBus/Compact Flash world): what is a yenta-compatible device? I know it's some how tied up in all of this, but googling it doesn't give me any usefull results. Or is this question/thread better asked on the linux-pcmcia list? Take care and stay safe. bruce ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problems with PHY on STK5200
In message <[EMAIL PROTECTED]> you wrote: > > I'm trying to compile a recent kernel from DENX "linuxppc_2_4_devel" for my > STK5200 using ELDK 3.1.1. It should compile and run fine. > It seems that the current kernel there is not configuring the PHY. It looks > like the link is configured for full-duplex (although it should be configured > half-duplex). What makes you think it should be half duplex only? > BTW: What is the normal way to reference a commit in a git-repository? I > haven't seen any revision numbers. You specify the git commit ID. > Can anybody explain what the driver should to? Or even better has some patch > to make it work? The driver should work :-) And it certainly does for me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell,Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Is not that the nature of men and women -- that the pleasure is in the learning of each other? -- Natira, the High Priestess of Yonada, "For the World is Hollow and I Have Touched the Sky", stardate 5476.3. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
>> - Cap the driver at 4 UARTs; > > Let's do this, but design the code to > allow more by just changing a #define. > >> Just randomly using some extra minors that aren't >> assigned to you isn't such a great idea. > > Maybe for a desktop or generic server where > you don't know what's going to be configured, > but it's not unusual to do so with custom > embedded systems. You can do whatever you want in your own stuff but that's not how things work in the mainstream Linux kernel. > The small experimental > or user allocations often don't cover what > is needed, so we just grab some allocation > from a device that isn't ever going to be > used on the system. Sure I've done that myself a few times, but this just doesn't fly for in-kernel drivers; those have their own ranges defined in devices.txt and don't use random other minors. Segher ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
Dan Malek wrote: > Don't worry about it for now. We'll just keep this in > mind when we make a major change someday in > the future. We may have a better solution then. Ok, what about udev? If a user is running udev, which supposedly doesn't care about minor numbers, won't the user still be limited to 4 UARTS? If so, is there a way for the driver to detect udev and allow 8 UARTS? -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
Since I'm probably the only one that really uses the driver for custom uses and cares.. On Mar 1, 2007, at 10:55 AM, Timur Tabi wrote: > Ok guys, I need a consensus here. Are we going to allocate a > second block of 4 minor numbers for the QE/CPM UART or not? not. > My driver already has a macro that limits the number of UARTS to 4, perfect. > I'll add a second TTY struct... Don't worry about it for now. We'll just keep this in mind when we make a major change someday in the future. We may have a better solution then. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
Dan Malek wrote: > People have used more than 4, but we just > allocated the additional /dev entries to cover > them. I know of only one time this has happened. > It's such a custom case that the other device > names didn't matter. Ok guys, I need a consensus here. Are we going to allocate a second block of 4 minor numbers for the QE/CPM UART or not? My driver already has a macro that limits the number of UARTS to 4, and it just uses minor numbers 47 through (47 + UCC_MAX_UART - 1). So my driver can easily be modified to spill into the Altic's range if some custom board needs it. I'll add a second TTY struct to handle the 2nd set of minor numbers if and only if devices-2.6+.txt is updated with that information. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 5:08 PM, Segher Boessenkool wrote: > Since you say no one has ever used more than 4 UARTs, > there are two options: People have used more than 4, but we just allocated the additional /dev entries to cover them. I know of only one time this has happened. It's such a custom case that the other device names didn't matter. > - Cap the driver at 4 UARTs; Let's do this, but design the code to allow more by just changing a #define. > Just randomly using some extra minors that aren't > assigned to you isn't such a great idea. Maybe for a desktop or generic server where you don't know what's going to be configured, but it's not unusual to do so with custom embedded systems. The small experimental or user allocations often don't cover what is needed, so we just grab some allocation from a device that isn't ever going to be used on the system. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Please help me with compiling the kernel for ML403
Mohammad,
The patches were not in the kernel version I was using (2.6.19). They are
for the TEMAC only, so they only need to be applied for networking support.
I have not used the montavista version, this is the free version of the
Linux kernel from kernel.org.
It did seem like you were mixing different methods. If you follow my steps
you should not have any problems.
Glenn
(Embedded Mohammad Sadegh Sadri <[EMAIL PROTECTED]>
image moved 03/01/2007 01:29 AM
to file:
pic31673.pcx)
To:Linux PPC Linux PPC
cc:<[EMAIL PROTECTED]>
Subject:Re: Please help me with compiling the kernel for ML403
Security Level:? Internal
Glenn,
I studied your post carefuly,
You are using a patch: paulus,
I looked at some parts of these patches,
most of them are already applied to the kernel,
Do I really need to apply these patches?
Is this true for newer versions of the kernel , like 2.6.20? or the devel
version from montavista
You have applied these patches to 2.6.14 , from kernel.org, Yes?
one of the persons here, told me that I'm mixing different methods for
building the kernel,
I think that he may be true, Am I using a correct set of tools?
Thanks.
Date: Wed, 28 Feb 2007 16:53:39 -0500
From: [EMAIL PROTECTED]
Subject: Re: Please help me with compiling the kernel for ML403
To: linuxppc-embedded@ozlabs.org
Message-ID:
Content-Type: text/plain; charset="us-ascii"
Mohammad,
I didn't have much success copying the entire BSP into the kernel. Please
see my post titled "Linux w/ML403 PLB TEMAC". It is basically the tutorial
of how I got Linux working on an ML403 board.
Glenn
(Embedded Mohammad Sadegh Sadri @ozlabs.org
image moved 02/28/2007 04:21 PM
to file:
pic26924.pcx)
Sent by:
[EMAIL PROTECTED]
To:
cc:
Subject:Please help me with compiling the kernel for ML403
Security Level:? Internal
Hi
It is some thing more than 2 weeks that I'm trying to compile the kernel
for ML403.
Posted to questions here, but unfortunately, didn't get any answer from the
experts here.
I have tested every thing I knew ( with my limited knowledge ) and now, I
really need your help.
I'm using the following set of tools:
EDK 8.2.02, ( Latest )
ELDK 4.1 ( Latest )
-I want to compile the 2.6.20 kernel, downloaded from kernel.org
-As the first step, in EDK, I choose linux 2.6 in software platform
generation settings,
-I generate the BSP.
-In the generated BSP , I convert all of the 40x strings to 403, also I
change the name of xparameters_ml40x to xparameters_ml403
-I copy the 2.6.20 kernel /eldk/ppc_4xx/usr/src/linux , and set all of the
needed env variables for cross compile, and set the needed changes in the
linux Makefile. ( ARCH and
CROSS_COMPILE )
-I copy the entire BSP into the root of the linux kernel.
-I edit the linux/arch/ppc/Kconfig file, and add these lines into it:
config XILINX_OCP
bool "Xilinx OCP"
default y
config XILINX_TEMAC
bool "Xilinx TEMAC"
default y
config XILINX_SYSACE
bool "Xilinx System ACE"
default y
config XILINX_EDK
bool "Xilinx EDK Support"
default y
-In the linux folder I execute the cow.tcl script provided with the BSP
from EDK ( I execute tclsh cow.tcl )
-I make a symbolic link , for config.h file, ( I go to linux/include/linux
and then ln -s autoconf.h config.h )
-I begin the menuconfig and set all of the needed parameters
-Now, I begin the make process by simply typing : make
- I encounter the following error:
arch/ppc/platforms/4xx/virtex.c:20: error: array type has incomplete
element type
arch/ppc/platforms/4xx/virtex.c:60: error: field name not in record or
union initializer
arch/ppc/platforms/4xx/virtex.c:60: error: (near initialization for
'core_ocp')
make[1]: *** [arch/ppc/platforms/4xx/virtex.o] Error 1
make: *** [arch/ppc/platforms/4xx] Error 2
- I can prevent this error by commenting these lines of
/arch/ppc/platforms/4xx/virtex.c file:
/* Have OCP take care of the serial ports. */
struct ocp_def core_ocp[] = {
#ifdef XPAR_UARTNS550_0_BASEADDR
{ .vendor = OCP_VENDOR_XILINX,
.function = OCP_FUNC_16550,
.index = 0,
.paddr = XPAR_UARTNS550_0_BASEADDR,
.irq = XPAR_INTC_0_UARTNS550_0_VEC_ID,
.pm= OCP_CPM_NA
},
#ifdef XPAR_UARTNS550_1_BASEADDR
{ .vendor =
New Bestcomm/FEC patches (was: Re: [PATCH 0/7] MPC5200 and Lite5200b low power modes)
Grant Likely wrote: > On 3/1/07, Domen Puncer <[EMAIL PROTECTED]> wrote: >> Hi! >> >> Patches are based on latest mainline git tree + fec patches: >> Fec_MPC5200_eth_driver.patch >> Copy_bestcomm_support_files_into_arch_powerpc.patch >> Make_FEC_work_on_the_lite5200.patch >> > ---8<---snip--->8--- >> I would appreaciate any comments, suggestions etc. > > Cool, good work. I'll try to do a proper review today. > > Note on the Bestcomm stuff; the patches that you've referenced above > will not be going into mainline. They will be replaced by a new set > of bestcomm/FEC patches, hopfully in the .22 timeframe, so your > patches there will need some rework. Hello, I am working on porting arch/powerpc Linux to a custom MPC5200B-based board, and currently using your 52xx-dev branch. Is this new set of bestcomm/FEC patches already in any of your publicly available branches, or is it something completely fresh? I am seeing some networking problems, and would be interested in giving new patches a try. Regards, Bartlomiej ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: lanana: Add major/minor entries for PPC QE UART devices
> We are making a very complicated problem > out of nothing. This hasn't caused any problems > in the past, and changing the existing names and > minors will cause problems for everyone today. > > Just leave it alone, fix up the documentation, > and have the driver print some warning if it > allocates more than 4 UARTs. > Dan has a point here. Now I clearly can't comment on how bad 8 is needed, but since this has been like this for a while, I'll have to assume 4 is covering most cases. Moving things to a different range _will_ be much worse for distro maintainers than driver developers. And I bet the latter is going to be minor work as things has been like this for a while. But we can still allocate 4 more at a different minor that distro's can _choose_ to use. Consider it an enhancement to the 4 we have had in the past. Torben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 0/7] MPC5200 and Lite5200b low power modes
On 3/1/07, Domen Puncer <[EMAIL PROTECTED]> wrote: > Hi! > > Patches are based on latest mainline git tree + fec patches: > Fec_MPC5200_eth_driver.patch > Copy_bestcomm_support_files_into_arch_powerpc.patch > Make_FEC_work_on_the_lite5200.patch > ---8<---snip--->8--- > > I would appreaciate any comments, suggestions etc. Cool, good work. I'll try to do a proper review today. Note on the Bestcomm stuff; the patches that you've referenced above will not be going into mainline. They will be replaced by a new set of bestcomm/FEC patches, hopfully in the .22 timeframe, so your patches there will need some rework. Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC5200, PLX9054 PCI Card - stalled DMA transfers
Hi, we're using a TQM5200S-Module (MPC5200) on a STK52xx-board with a PLX9054-based PCI card. The 2.4.25-kernel on the 3.1.1 ELDK had big problems to map the PCI resources of this card, so I tried the latest 2.6.19.2-kernel of the 4.1 ELDK. This kernel mapped successfully the PCI resources on this card. After building the latest PLX driver on the 2.6.19-kernel (I had to make some changes for the .19 kernel and for some litte/big endian issues) I was able to transfer data with programmed I/O. But as this is too slow I like to use the DMA functions of this device and here is the problem: PLX provides an example program for scatter/gather DMA. This program works with their latetst driver on a linux PC. But on the TQM5200 the 'Channel 0 done' flag of the DMASR0 register is never set after starting the DMA transfer. What can be the reason for this? The debug output of the driver looks O.K., but waiting for the DMA done interrupt gives a timeout, because the flag is not set. I wrote some test patterns in my DMA buffer before the DMA transfer and no byte of the buffer was altered, so the DMA engine seems not to be able to write a single byte. Has anybody this or a similar card running on a ppc environment? Any ideas what I can do? Thanks in advance and bye, -- Dipl. Ing. Oliver Rutsch EMail: [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
i2c driver for mpc8xx
hi all, anyone knows if an i2c driver for the i2c controller of MPC88x processor in linux kernel 2.6.19? I tried to find it but I didn't find one. Thank you, Melinda - Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started!___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kernel support for the TI1520 PCI-CardBus bridge?
Bruce, --- [EMAIL PROTECTED] wrote: > Hi all, > > We're designing a new product and we want to put a > CF card in it. We're > thinking the easiest way to do that is to put in a > PCI-CF bridge and we > would like to use the TI1520 because it's industrial > rated which we need. > We can get the parts but TI is refusing to give us > any support because > they're devoting 100% of their time to dealing with > the Vista release. I'm > curious if anyone has ever successfully gotten this > part to work in linux. > I found it listed in pci_ids.h, but that doesn't > mean it's actually > used/working. I'm not looking for a detailed > explination right now, we're > just trying to gage if this part would be a couple > of weeks of work or a > couple of months. Thanks for any info. If you don't need hot-plugging and happen to be using either a Freescale PowerQUICCx or IBM/AMCC 4xx chip, you might consider connecting directly to the local bus and operating in TrueIDE mode. This has limitations, but has been done many times. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Problems with PHY on STK5200
Hi, I'm trying to compile a recent kernel from DENX "linuxppc_2_4_devel" for my STK5200 using ELDK 3.1.1. It seems that the current kernel there is not configuring the PHY. It looks like the link is configured for full-duplex (although it should be configured half-duplex). There is no informative output about the PHY after the line eth0: Phy @ 0x0, type LXT971 (0x001378e2) --- I have traced this change of behaviour back to a commit on 2005-09-04 22:41:06. This is a major restructuring/rework of the file "arch/ppc/5xxx_io/fec.c". BTW: What is the normal way to reference a commit in a git-repository? I haven't seen any revision numbers. The versions also show different program flow (with MPC5xxx_FEC_DEBUG set to 2). The old version goes: - mpc5xxx_fec_init() - mpc5xxx_fec_restart() - PHY gets identified here - mpc5xxx_fec_open() - autonegotiation here - mpc5xxx_fec_restart() The new one goes - mpc5xxx_fec_init() - mpc5xxx_fec_open() - mpc5xxx_fec_restart() - PHY gets identified here The new version has some bad (or at least dead) code in the funtion mpc5xxx_fec_setup(). However, I don't understand enough of the drivers design to see how to fix this. Can anybody explain what the driver should to? Or even better has some patch to make it work? Thanks in advance /Jan-Hinnerk Dumjahn ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kernel support for the TI1520 PCI-CardBus bridge?
On Thursday 01 March 2007 02:35, [EMAIL PROTECTED] wrote: > Hi all, > > We're designing a new product and we want to put a CF card in it. We're > thinking the easiest way to do that is to put in a PCI-CF bridge and we > would like to use the TI1520 because it's industrial rated which we need. > We can get the parts but TI is refusing to give us any support because > they're devoting 100% of their time to dealing with the Vista release. I'm > curious if anyone has ever successfully gotten this part to work in linux. > I found it listed in pci_ids.h, but that doesn't mean it's actually > used/working. I'm not looking for a detailed explination right now, we're > just trying to gage if this part would be a couple of weeks of work or a > couple of months. Thanks for any info. I got a TI cardbus controller PCI1520IPDV working in a embedded PPC system with little modifications to kernel 2.4.25, but i didn't found a common configuration for the I/O-space that works for all type of cards (cardbus and pcmcia). I tested some pcmcia cards, like WLAN, Ethernet, pcmcia harddisk and CF-Adapter with a different kernel configuration as for cardbus cards. Frank ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [u-boot patch] support lite5200b wakeup in u-boot
On Thursday 01 March 2007 08:59, Domen Puncer wrote: > U-Boot part of Lite5200b low power mode support. > Puts SDRAM out of self-refresh and transfers control to > address saved at physical 0x0 Please post this patch to the U-Boot mailing list. Best regards, Stefan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 7/7] lite5200b suspend: low-power mode
Low-power mode implementation for Lite5200b.
A patch to U-Boot that wakes up SDRAM, and transfers control
to address saved at physical 0x0 is needed.
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Index: grant.git/arch/powerpc/platforms/52xx/lite5200_pm.c
===
--- /dev/null
+++ grant.git/arch/powerpc/platforms/52xx/lite5200_pm.c
@@ -0,0 +1,101 @@
+#include
+#include
+#include
+#include
+#include
+#include "bestcomm.h"
+
+extern void lite5200_low_power(void *sram, void *mbar);
+extern int mpc52xx_pm_enter(suspend_state_t);
+extern void mpc52xx_pic_suspend(void);
+extern void mpc52xx_pic_resume(void);
+
+static int lite5200_pm_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ case PM_SUSPEND_MEM:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+static int lite5200_pm_prepare(suspend_state_t state)
+{
+ return 0;
+}
+
+static int lite5200_pm_enter(suspend_state_t state)
+{
+ int err = 0;
+ struct mpc52xx_gpio __iomem *gpio;
+ void __iomem *mbar;
+ u32 gpio_saved_pc;
+
+ /* deep sleep? let mpc52xx code handle that */
+ if (state == PM_SUSPEND_STANDBY)
+ return mpc52xx_pm_enter(state);
+
+ if (state != PM_SUSPEND_MEM)
+ return -ENOSYS;
+
+ /* Map zones */
+ gpio = mpc52xx_find_and_map("mpc5200-gpio");
+ if (!gpio) {
+ printk(KERN_ERR "%s:%i Error mapping io zones\n", __func__,
__LINE__);
+ return -ENOSYS;
+ }
+
+ /* save ie. ethernet pins configuration */
+ gpio_saved_pc = in_be32(&gpio->port_config);
+
+ mpc52xx_sdma_suspend();
+ mpc52xx_pic_suspend();
+
+
+ mbar = ioremap_nocache(0xf000, 0x8000);
+ /* is there a nicer way? */
+ if (!mbar) {
+ printk(KERN_ERR "%s:%i Error mapping registers\n", __func__,
__LINE__);
+ err = -ENOSYS;
+ goto out_unmap;
+ }
+ lite5200_low_power(sdma.sram, mbar);
+ iounmap(mbar);
+
+
+ out_be32(&gpio->port_config, gpio_saved_pc);
+ iounmap(gpio);
+
+ mpc52xx_setup_cpu();
+
+ mpc52xx_pic_resume();
+ mpc52xx_sdma_resume();
+
+ return 0;
+
+ out_unmap:
+ iounmap(gpio);
+ return err;
+}
+
+static int lite5200_pm_finish(suspend_state_t state)
+{
+ return 0;
+}
+
+static struct pm_ops lite5200_pm_ops = {
+ .valid = lite5200_pm_valid,
+ .prepare= lite5200_pm_prepare,
+ .enter = lite5200_pm_enter,
+ .finish = lite5200_pm_finish,
+};
+
+static int __init lite5200_pm_init(void)
+{
+ pm_set_ops(&lite5200_pm_ops);
+ return 0;
+}
+
+arch_initcall(lite5200_pm_init);
Index: grant.git/arch/powerpc/platforms/52xx/lite5200_sleep.S
===
--- /dev/null
+++ grant.git/arch/powerpc/platforms/52xx/lite5200_sleep.S
@@ -0,0 +1,419 @@
+#include
+#include
+#include
+#include
+
+
+#define SDRAM_MODE 0x100
+#define SDRAM_CTRL 0x104
+#define SC_MODE_EN (1<<31)
+#define SC_CKE (1<<30)
+#define SC_REF_EN (1<<28)
+#define SC_SOFT_PRE(1<<1)
+
+#define GPIOW_GPIOE0xc00
+#define GPIOW_ODE 0xc04
+#define GPIOW_DDR 0xc08
+#define GPIOW_DVO 0xc0c
+#define GPIOW_INTEN0xc10
+
+#define CDM_CE 0x214
+#define CDM_SDRAM (1<<3)
+
+
+// about 2000 cpu cycles for one sdram cycle here
+// just increase, to be on the safe side?
+#define TCK5000
+
+
+#define DONT_DEBUG 1
+
+// helpers... beware: r10 and r4 are overwritten
+#define SAVE_SPRN(reg, addr) \
+ mfspr r10, SPRN_##reg;\
+ stw r10, ((addr)*4)(r4);
+
+#define LOAD_SPRN(reg, addr) \
+ lwz r10, ((addr)*4)(r4);\
+ mtspr SPRN_##reg, r10;\
+ sync; \
+ isync;
+
+// XXX it uses cca. 10 mA less if registers are saved in .text. WTF
+// is this still true?
+// .data
+registers:
+ .space 0x5c*4
+// .text
+
+// --
+// low-power mode with help of M68HLC908QT1
+
+ .globl lite5200_low_power
+lite5200_low_power:
+
+ mr r7, r3 // save SRAM va
+ mr r8, r4 // save MBAR va
+
+ // setup wakeup address for u-boot at physical location 0x0
+ lis r3, [EMAIL PROTECTED]
+ lis r4, [EMAIL PROTECTED]
+ ori r4, r4, [EMAIL PROTECTED]
+ sub r4, r4, r3
+ stw r4, 0(r3)
+
+
+ // save stuff BDI overwrites
+ /* save 0xf0 (0xe0->0x100 gets overwritten when BDI connected;
+* even when CONFIG_BDI* is disabled and MMU XLAT commented;
heisenbug?))
+* WARNING: self-refresh doesn't seem to work when BDI2000 is connected,
+* possibly because BDI sets SDRAM registers
[u-boot patch] support lite5200b wakeup in u-boot
U-Boot part of Lite5200b low power mode support.
Puts SDRAM out of self-refresh and transfers control to
address saved at physical 0x0
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
diff --git a/board/icecube/icecube.c b/board/icecube/icecube.c
index 9b222da..4b35776 100644
--- a/board/icecube/icecube.c
+++ b/board/icecube/icecube.c
@@ -42,6 +42,54 @@ # else
#include "mt48lc16m16a2-75.h"
# endif
#endif
+
+#ifdef CONFIG_LITE5200B
+/* u-boot part of low-power mode implementation */
+#define SAVED_ADDR (*(void **)0x)
+#define PSC2_4 0x02
+
+void lite5200b_wakeup(void)
+{
+ unsigned char wakeup_pin;
+ void (*linux_wakeup)(void);
+
+ /* check PSC2_4, if it's down "QT" is signaling we have a wakeup
+* from low power mode */
+ *(vu_char *)MPC5XXX_WU_GPIO_ENABLE = PSC2_4;
+ __asm__ volatile ("sync");
+
+ wakeup_pin = *(vu_char *)MPC5XXX_WU_GPIO_DATA_I;
+ if (wakeup_pin & PSC2_4)
+ return;
+
+ /* acknowledge to "QT"
+* by holding pin at 1 for 10 uS */
+ *(vu_char *)MPC5XXX_WU_GPIO_DIR = PSC2_4;
+ __asm__ volatile ("sync");
+ *(vu_char *)MPC5XXX_WU_GPIO_DATA = PSC2_4;
+ __asm__ volatile ("sync");
+ udelay(10);
+
+ /* put ram out of self-refresh */
+ *(vu_long *)MPC5XXX_SDRAM_CTRL |= 0x8000; // mode_en
+ __asm__ volatile ("sync");
+ *(vu_long *)MPC5XXX_SDRAM_CTRL |= 0x5000; // cke ref_en
+ __asm__ volatile ("sync");
+ *(vu_long *)MPC5XXX_SDRAM_CTRL &= ~0x8000; // !mode_en
+ __asm__ volatile ("sync");
+ udelay(10); /* wait a bit */
+
+ /* jump back to linux kernel code */
+ linux_wakeup = SAVED_ADDR;
+ printf("\n\nLooks like we just woke, transferring control to 0x%08lx\n",
+ linux_wakeup);
+ linux_wakeup();
+}
+#else
+#define lite5200b_wakeup
+#endif
+
+
#ifndef CFG_RAMBOOT
static void sdram_start (int hi_addr)
{
@@ -208,6 +256,8 @@ #endif /* CFG_RAMBOOT */
__asm__ volatile ("sync");
}
+ lite5200b_wakeup();
+
return dramsize + dramsize2;
}
diff --git a/include/mpc5xxx.h b/include/mpc5xxx.h
index 1d20d1d..c7eb090 100644
--- a/include/mpc5xxx.h
+++ b/include/mpc5xxx.h
@@ -189,6 +189,7 @@ #define MPC5XXX_WU_GPIO_ENABLE (MPC5XXX
#define MPC5XXX_WU_GPIO_ODE (MPC5XXX_WU_GPIO + 0x0004)
#define MPC5XXX_WU_GPIO_DIR (MPC5XXX_WU_GPIO + 0x0008)
#define MPC5XXX_WU_GPIO_DATA(MPC5XXX_WU_GPIO + 0x000c)
+#define MPC5XXX_WU_GPIO_DATA_I (MPC5XXX_WU_GPIO + 0x0020)
/* PCI registers */
#define MPC5XXX_PCI_CMD(MPC5XXX_PCI + 0x04)
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
