PCI support on the ML310 (Linux 2.4/2.6) (Juliana Su)
Huang, Bin
bhuang2 at uncc.edu
Sat Aug 9 09:49:22 EST 2008
There are a lot of pitfalls that might give you such kernel panic and I am sure I did not have a chance to experience them all. But I can share with you my check list for the panic of hanging at "Now booting the kernel".
Firstly, you may uncheck PCI bus option in your kernel config. If you still cannot get "Now booting the kernel" passed, then you need to make sure there are 128Mb ddr RAM on your ML310. From your booting message, I assume you have 128Mb RAM. But if actually you don't have that much size, the kernel may get confused and stuck.
Secondly, if you see this panic only when enabling PCI bus option, then I suggest you look into your arch/ppc/kernel/ppc405_pci.c, make sure the kernel actually execute this piece of code:
#ifdef CONFIG_XILINX_OCP
/* Eliminate "unused variable" warning for pcip. Optimizer removes. */
pcip = NULL;
new_pmm_min = PPC405_PCI_LOWER_MEM;
new_pmm_max = PPC405_PCI_UPPER_MEM;
Some mainline kernel does not have CONFIG_XILINX_OCP setting for you , and ML310/ML410 does need them to boot up PCI bus.
Let me know if you still have problem.
Bin
-----Original Message-----
From: linuxppc-embedded-bounces+bhuang2=uncc.edu at ozlabs.org 代表 linuxppc-embedded-request at ozlabs.org
Sent: 8/5/2008 (星期二) 22:00
To: linuxppc-embedded at ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 48, Issue 7
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded at ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request at ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner at ozlabs.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. Re: floating point support in the driver. (David Hawkins)
2. Re: PCI support on the ML310 (Linux 2.4/2.6) (Juliana Su)
----------------------------------------------------------------------
Message: 1
Date: Tue, 05 Aug 2008 09:53:45 -0700
From: David Hawkins <dwh at ovro.caltech.edu>
Subject: Re: floating point support in the driver.
To: Misbah khan <misbah_khan at engineer.com>
Cc: linuxppc-embedded at ozlabs.org
Message-ID: <48988599.5020008 at ovro.caltech.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Misbah,
> I am running the algorithm on OMAP processor (arm-core)
> and i did tried the same on iMX processor which
> takes 1.7 times more than OMAP.
Ok, thats a 10,000ft benchmark. The observation being
that it fails your requirement.
How does that time compare to the operations
required, and their expected times?
> It is true that the algorithm is performing the vector
> operation which is blowing the cache.
Determined how? Obviously if your cache is 16K and your
data is 64K, there's no way it'll fit in there at once,
but the algorithm could be crafted such that 1K at a time
was processed, while another data packet was moved onto
the cache ... but this is very processor specific.
> But the question is How to lock the cache ? In driver
> how should we implement the same ?
>
> An example code or a document could be helpful in this regard.
Indeed :)
I have no idea how the OMAP works, so the following are
just random, and possibly incorrect ramblings ...
The MPC8349EA startup code uses a trick where it zeros
out sections of the cache while providing an address.
Once the addresses and zeros are in the cache, its locked.
From that point on, memory accesses to those addresses
result in cache 'hits'. This is the startup stack used
by the U-Boot bootloader.
If something similar was done under Linux, then *I guess*
you could implement mmap() and ioremap() the section of
addresses associated with the locked cache lines.
You could then DMA data to and from the cache area,
and run your algorithm there. That would provide you
'fast SRAM'.
However, you might be able to get the same effect by
setting up your processing algorithm such that it handled
smaller chunks of data.
Feel free to explain your data processing :)
Cheers,
Dave
------------------------------
Message: 2
Date: Tue, 05 Aug 2008 15:09:28 -0400
From: Juliana Su <js084 at bucknell.edu>
Subject: Re: PCI support on the ML310 (Linux 2.4/2.6)
To: linuxppc-embedded at ozlabs.org
Message-ID: <4898A568.10502 at bucknell.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
Thanks for your reply, Bin! I checked system.mhs and "C_BRIDGE_IDSEL_ADDR_BIT" was set to 16, but the code that was in pci_init( ) was the code for as if "C_BRIDGE_IDSEL_ADDR_BIT" was set to 24. After replacing the code in pci_init( ), the PCI now initializes. However, after the ML310 initialization finishes, the system hangs at "Now booting the kernel". I remember encountering this problem when I was porting Linux 2.6. It had to do with a linker problem and after rolling back to gcc-4.0.2, I got past the problem. I'm using Linux 2.4, though, so that solution will not work here... I am using UART Lite and I made sure that it (and not UART 16550) was selected in the kernel configuration and that "Console on UART Lite port" was selected as well. I also made sure that UART Lite was what was chosen when I built the BSP. Oh, and there is a /dev/ttyUL0 device node in my root file system. I even did a "make mrproper" and re-did the kernel configuration, but that did not solve my pro
blem. Any suggestions? Thanks!
-Juliana
Xilinx ML310 Board-Specific Initialization:
ppb_init: dev = 9, id = ac23104c
pci_scan: bus 0, device 0, id 030010ee
pci_scan: bus 0, device 1, id 545110b9
pci_scan: bus 0, device 2, id 153310b9
pci_scan: bus 0, device 3, id 545710b9
pci_scan: bus 0, device 7, id 12298086
pci_scan: bus 0, device 9, id ac23104c
pci_scan: bus 0, device 12, id 710110b9
pci_scan: bus 0, device 15, id 523710b9
sio_init: Device ID = 53 15, Revision = f3.
sio_init: LPT1 base = 0x0378, irq = 5.
sio_init: COM1 base = 0x03f8, irq = 4.
sio_init: COM2 base = 0x02f8, irq = 3.
sio_init: KBC irq = 1, PS2 irq = 1.
sio_init: Super I/O initialization complete.
loaded at: 00400000 004E91F4
board data at: 004E613C 004E6154
relocated to: 00406410 00406428
zimage at: 00406BF9 004E5566
avail ram: 004EA000 08000000
Linux/PPC load: console=ttyUL0,9600 ip=off root=/dev/xsysace/disc0/part2 rw
Uncompressing Linux...done.
Now booting the kernel
------------------------------
Message: 11
Date: Tue, 5 Aug 2008 12:48:29 -0400
From: "Huang, Bin" <bhuang2 at uncc.edu>
Subject: re ?PCI support on the ML310 (Linux 2.4/2.6)
To: <linuxppc-embedded at ozlabs.org>
Message-ID:
<61B0EE7C247C1349881F63414448FC1F920F25 at EXEVS06.its.uncc.edu>
Content-Type: text/plain; charset="gb2312"
As far as I know, only MVista has complete PCI support for ML310. I have
been migrating their PCI stuff to 2.6 kernel for couple of months so I might
understand what you are suffering here.
If your system hangs just after "Xilinx ML310 Board-Specific
Initialization:", then probably there is something wrong with your OPB-PCI
core on virtex-2 FPGA. I highly recommend you double check the value of
"C_BRIDGE_IDSEL_ADDR_BIT" within your system.mhs file.
When the 2.4/2.6 kernel tries to initialize pci core, it has to do self-
configuration first. If the wrong address is assigned in pci_init(), then
the kernel could not proceed any more.
Here is what you need to take care of:
for C_BRIDGE_IDSEL_ADDR_BIT = 24, use
pci_init()
{
/* self-configuration */
WR32(PCI_CONFIG_ADDR, htole32(0x80004004)); // address
WR32(PCI_CONFIG_DATA, htole32(0xffff0147)); // data
/* max latency timer on bridge */
WR32(PCI_CONFIG_ADDR, htole32(0x8000400c)); // address
WR32(PCI_CONFIG_DATA, htole32(0x0000ff00)); // data
/* max bus number */
WR32(PCI_CONFIG_ADDR+8, htole32(0xff000000));
};
for C_BRIDGE_IDSEL_ADDR_BIT = 16, use
pci_init()
{
/* self-configuration */
WR32(PCI_CONFIG_ADDR, htole32(0x80000004)); // address
WR32(PCI_CONFIG_DATA, htole32(0xffff0147)); // data
/* max latency timer on bridge */
WR32(PCI_CONFIG_ADDR, htole32(0x8000000c)); // address
WR32(PCI_CONFIG_DATA, htole32(0x0000ff00)); // data
/* max bus number */
WR32(PCI_CONFIG_ADDR+8, htole32(0xff000000));
};
You may check Xilinx's user guide 241 for more details.
Porting BSP from EDK9.1 to MVista 2.4 should be quite straightforward, but
porting them to 2.6 virtex is a little bit vague. If you are trying to use IDE
southbridge, I could recommend you start from 2.6.10 rather than 2.6 virtex
because driver/ide/pci/alim15x3.c has been updated a lot and I
hate to say that a none-disclosure agreement on alim15x3 makes it time consuming
to understand super I/O on ml310. If you just need PCI bus function, then life
will much more easier but you still need be care of about opb-pci core parameters
Bin
-----Original Message-----
From: linuxppc-embedded-bounces+bhuang2=uncc.edu at ozlabs.org ?? linuxppc-embedded-request at ozlabs.org
Sent: 8/4/2008 (???) 22:00
To: linuxppc-embedded at ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 48, Issue 5
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded at ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request at ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner at ozlabs.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. PCI support on the ML310 (Linux 2.4/2.6) (Juliana Su)
2. Re: Creating a wrapped zImage.initrd -- can't start the
trampoline? (Grant Likely)
3. Re: suffisant space for U-Boot, Linux and an initrd image ?
(4MB SDRAM) (Wolfgang Denk)
----------------------------------------------------------------------
Message: 1
Date: Mon, 04 Aug 2008 16:08:33 -0400
From: Juliana Su <js084 at bucknell.edu>
Subject: PCI support on the ML310 (Linux 2.4/2.6)
To: linuxppc-embedded at ozlabs.org
Message-ID: <489761C1.8030805 at bucknell.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I am trying to get PCI support on the ML310. I was able to port Linux
2.6 (linux-2.6-virtex from Secret Lab) onto the board, but unfortunately
there is no PCI support in the kernel. When I enabled PCI support, I got
the same errors (see below) that were reported on the Secret Lab Wiki.
CC arch/ppc/syslib/ppc4xx_setup.o
arch/ppc/syslib/ppc4xx_setup.c: In function `ppc4xx_map_io':
arch/ppc/syslib/ppc4xx_setup.c:118: error: `PPC4xx_PCI_IO_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:118: error: (Each undeclared identifier
is reported only once
arch/ppc/syslib/ppc4xx_setup.c:118: error: for each function it appears in.)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_SIZE'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:120: error: `PPC4xx_PCI_CFG_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_SIZE'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:122: error: `PPC4xx_PCI_LCFG_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_SIZE'
undeclared (first use in this function)
make[1]: *** [arch/ppc/syslib/ppc4xx_setup.o] Error 1
make: *** [arch/ppc/syslib] Error 2
I went back to Linux 2.4 (v2.4.20_mvl31-ml300), but the system hangs
during ml310_init( ), specifically when it gets to pci_init( ), in
ml310.c. I put some print statements in ml310.c to debug and found out
that it gets pass the first two lines in pci_init( ) before hanging.
Basically, all I get on my screen is:
Xilinx ML310 Board-Specific Initialization:
ml310_init( ) looks like this:
void
ml310_init()
{
prints("\n\n");
prints("Xilinx ML310 Board-Specific Initialization:\n");
prints("\n");
pci_init();
ppb_init(9);
pci_scan();
sio_init();
sbr_init();
};
and pci_init( ) looks like this:
void
pci_init()
{
/* self-configuration */
WR32(PCI_CONFIG_ADDR, htole32(0x80004004)); // address
WR32(PCI_CONFIG_DATA, htole32(0xffff0147)); // data
/* max latency timer on bridge */
WR32(PCI_CONFIG_ADDR, htole32(0x8000400c)); // address
WR32(PCI_CONFIG_DATA, htole32(0x0000ff00)); // data
/* max bus number */
WR32(PCI_CONFIG_ADDR+8, htole32(0xff000000));
};
ml310.c was generated when I made the BSP in Xilinx EDK 9.1. I copied
it, along with the other files from the BSP, into the kernel source. I
am using a Crosstool cross-compiler, gcc-3.4.1-glibc-2.3.3. I have also
tried the linuxppc-2.4 and mvistappc_2_4_devel kernels from
source.mvista.com, but those both crashed with similar (and several)
errors concerning ide-taskfile.c during compilation.
Is anybody aware of how to manually map the PCI constants in 2.6 and
willing to help me map them? Does anybody have an idea why pci_init( )
is getting stuck? Any suggestions, in general, would be greatly appreciated.
Let me know if I need to provide more information or code. Thanks!
-Juliana
------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
End of Linuxppc-embedded Digest, Vol 48, Issue 7
************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 10394 bytes
Desc: not available
URL: <http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20080808/758c71be/attachment-0001.bin>
More information about the Linuxppc-embedded
mailing list