* [Problem] linux 2.6.14 kernel hang up after the uImage uncompressed successfully
From: Jonathan Qiang @ 2006-01-10 3:06 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]
Hi,
I am doing booting linux kernel 2.6.14.5 from kernel.org on a kind of
embedded ppc board, where the chip mpc8272 has been settled.
But after u-boot(1.1.4) finished booting itself and uncompressed the
uImage(2.6.14.5 based). the kernel can not boot
Successfully. It stop somewhere. the script is below:
U-Boot 1.1.4 (Jan 3 2006 - 15:00:41)
MPC8272 Reset Status: Check Stop, External Soft, External Hard
MPC8272 Clock Configuration
- Bus-to-Core Mult 5x, VCO Div 2, 60x Bus Freq 20-60 , Core Freq
100-300
- dfbrg 1, corecnf 0x1b, busdf 7, cpmdf 1, plldf 0, pllmf 7
- vco_out 528000000, scc_clk 132000000, brg_clk 33000000
- cpu_clk 330000000, cpm_clk 264000000, bus_clk 66000000
- pci_clk 22000000
CPU: MPC8272 (HiP7 Rev 14, Mask 1.0 1K50M) at 330 MHz
I2C: ready
DRAM: SDRAM configuration:
Refresh rate = 47, CAS latency = 3, Using Page Based Interleave
Total size: 32 MB
FLASH Dectected: FLASH MFP, new id is 0x0089, Device ID is 0x8922
32 MB
In: serial
Out: serial
Err: serial
Ethos version: ac21 (DEVID:ac2, DEVVER:1, MFGVER: 1)
CFG_CMXFCR_VALUE=0x00370000, CFG_CMXFCR_MASK=0x007F0000
Net: FCC2 ETHERNET
Hit any key to stop autoboot: 0
Using FCC2 ETHERNET device
## Booting image at 00200000 ...
Image Name: Linux-2.6.14.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 750080 Bytes = 732.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Then I have tried to use BDI2000 to debug the kernel, It seems that the
kernel can passed on console_init function. But still no message came
out even printk(KERN_NOTICE); and printk(linux_banner);
[-- Attachment #2: Type: text/html, Size: 13796 bytes --]
^ permalink raw reply
* RE: mpc8260 fec enet transmit time out
From: atul.sabharwal @ 2006-01-10 2:39 UTC (permalink / raw)
To: r26191, hubert.loewenguth, Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 7253 bytes --]
How do you know that the FEC MAC & PHY are connected correctly? Check
the CLK's generated by the PHY.
Any signal issues (with a scope) ? Can you read/write the Phy registers
using the MDIO channel?
Check the link register in the Phy if it gives any false link status?
Also, the driver might have auto switching
Of Ethernet interfaces or might have a timeout and stop any
transmit/receive which is causing the lockup.
Force the driver to re-initialize after a timeout might be a workaround.
--
Atul
________________________________
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Ho
Jeffrey-r26191
Sent: Monday, January 09, 2006 6:27 PM
To: 'hubert.loewenguth'; Linuxppc-embedded@ozlabs.org
Subject: RE: mpc8260 fcc enet transmit time out
On MPC8560 port of linuxppc-2.4, on the Gianfar driver for TSEC and FEC,
there is a mode call phy polling mode can be enable.
In one of our hw, we are using realtek 10/100phy which don't have
interrupt as well.
We config that phy to use the polling mode in Gianfar. We can do plug
and unplug with no problem.
My suggetsion is to check how that driver do the polling and use it with
your fcc_enet.
Regards,
Jeffrey Ho
Freescale Semiconductor HK Ltd
Tel: 852-26668050
________________________________
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
hubert.loewenguth
Sent: Tuesday, January 10, 2006 1:27 AM
To: Linuxppc-embedded@ozlabs.org
Subject: mpc8260 fcc enet transmit time out
hi the community.
I have already posted a question about my problem but it seems
that nobody has encounter the same matter.
So I have made numerous tests and researches and seeing that I
still have not succeed in solving it, I try again tyo send you my bug.
I use a MPC8260 with linux 2.4.20.
The problem is with the fcc_enet driver.
I have no MII phy interrupt line with my LXT971 Phy in front of
the powerpc.
Seeing that I have no interrupt line, I have configured the
driver to be in half duplex, and the LXT971 too.
I'm sure that the driver is in half-duplex mode an the LXT971
too, and the auto-negociation is ok.
Everything works fine, but, if I do successive plugs/unplugs
during important data transfert, The driver enter into an infinite loop:
# NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f690.
Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
...
1c00 055c 011d486a
3c00 05ea 011d406a
Rx @base c019f608 :
9c00 0040 01f3e000
9c00 0040 01f3e800
...
9c00 0040 01f3d000
bc00 0040 01f2f800
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f698.
Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
1c00 05ea 011ce06a
.....
I have found, on the linux-embended forum, a personn who has the
same problem:
http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html
But I'm sure about my pin connections ans so the reponse to this
personn doesn't solve my problem
More interresting this one :
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html
This personn seems to have the same troubleshouting than me .
He has tried to apply the patch provided by freescale, but it
doesn't seem to correct it.
So I have had just a little piece of trace in order to see when
this infernal loop appear.
I have added some trace in the fcc_enet_start_xmit .
has you know, after some kind of transmit errors, the
transmitter need to be restarted, and so I have added some traces to see
when it is restarted
/* Some transmit errors cause the transmitter to shut
* down. We now issue a restart transmit. Since the
* errors close the BD and update the pointers, the
restart
* _should_ pick up without having to reset any of our
* pointers either. Also, To workaround 8260 device
erratum
* CPM37, we must disable and then re-enable the
transmitter
* following a Late Collision, Underrun, or Retry Limit
error.
*/
# UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
UNDERRUN ! ==> RESTART
CARRIER LOST !
........
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f778 tx_free 0 cur_rx c019f690.
Tx @base c019f708 :
1c02 055c 012cd86a
9c00 05ea 012cd06a
9c00 05ea 012f706a
9c00 05ea 012cf06a
9c00 05ea 012cf86a
9c00 05ea 0118506a
Some personns have said me to try with 2.6 drivers but it's
exactly the same problem.
( even if I'm a little bit surprised to see that with the 2.6
version drivers seems to be uncompatible with boards wich use MDIO
without PHY
interrupt.the #define PHY_INTERRUPT condition of the 2.4 drivers
version has
disapeared => with this new drivers you can't use MDIO without
PHY interrupt !!
it was possible in the 2.4 version.
- seeing that the "fep->link" value is enabled only on a PHY
interrupt .
I can't have this condition OK without PHY interrupt.
"fep->link" can be asserted in the mii_parse_sr function, but
has it is
indicated in the comment in the drivers :
"/* Somehow does the 971 tell me that the link is down
* the first read after power-up.
* read here to get a valid value in ack_int */"
That's true, the LXT 971A tell that the link is down, and seeing
that I
have no interrupt, the fep->link is never asserted again.
So, I have commented the first lines of the fcc_enet_start_xmit
function
which verify the value of fep->link.
I have added a #ifdef PHY_INTERRUPT condition before installing
the ISR
for this interrupt.
And thanks to that, I have been able to test the new driver 2.6
.
But unfortunetly this doesn't solve my problem.)
So 2.6 driver is not the solution of my problem.
I'm asking myself if this can be due to CPM21, or CPM22, or
CPM119 known bugs on mpc8260 ?
(see
http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf ) but
I don't think so.
Perhaps, I imagine that in fact the MPC8260 transmitter doesn't
restart correctly ?
(Also, To workaround 8260 device erratum
* CPM37, we must disable and then re-enable the
transmitter
* following a Late Collision, Underrun, or Retry Limit
error)
Is there anybody having encounter the same problem?
Is there anybody having done some test of numerous plug/unplug
during important data transfert with a half-duplex connection on
mpc8260?
Is there anybody having an idea to help me ?
Thanks to the community for any help, I'm really desepareted
here
(PS : sorry for my bad english)
[-- Attachment #2: Type: text/html, Size: 15602 bytes --]
^ permalink raw reply
* RE: mpc8260 fcc enet transmit time out
From: Ho Jeffrey-r26191 @ 2006-01-10 2:26 UTC (permalink / raw)
To: 'hubert.loewenguth', Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 6248 bytes --]
On MPC8560 port of linuxppc-2.4, on the Gianfar driver for TSEC and FEC, there is a mode call phy polling mode can be enable.
In one of our hw, we are using realtek 10/100phy which don't have interrupt as well.
We config that phy to use the polling mode in Gianfar. We can do plug and unplug with no problem.
My suggetsion is to check how that driver do the polling and use it with your fcc_enet.
Regards,
Jeffrey Ho
Freescale Semiconductor HK Ltd
Tel: 852-26668050
_____
From: linuxppc-embedded-bounces@ozlabs.org [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of hubert.loewenguth
Sent: Tuesday, January 10, 2006 1:27 AM
To: Linuxppc-embedded@ozlabs.org
Subject: mpc8260 fcc enet transmit time out
hi the community.
I have already posted a question about my problem but it seems that nobody has encounter the same matter.
So I have made numerous tests and researches and seeing that I still have not succeed in solving it, I try again tyo send you my bug.
I use a MPC8260 with linux 2.4.20.
The problem is with the fcc_enet driver.
I have no MII phy interrupt line with my LXT971 Phy in front of the powerpc.
Seeing that I have no interrupt line, I have configured the driver to be in half duplex, and the LXT971 too.
I'm sure that the driver is in half-duplex mode an the LXT971 too, and the auto-negociation is ok.
Everything works fine, but, if I do successive plugs/unplugs during important data transfert, The driver enter into an infinite loop:
# NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f690.
Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
...
1c00 055c 011d486a
3c00 05ea 011d406a
Rx @base c019f608 :
9c00 0040 01f3e000
9c00 0040 01f3e800
...
9c00 0040 01f3d000
bc00 0040 01f2f800
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f698.
Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
1c00 05ea 011ce06a
.....
I have found, on the linux-embended forum, a personn who has the same problem:
http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html <http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html>
But I'm sure about my pin connections ans so the reponse to this personn doesn't solve my problem
More interresting this one :
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html <http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html>
This personn seems to have the same troubleshouting than me .
He has tried to apply the patch provided by freescale, but it doesn't seem to correct it.
So I have had just a little piece of trace in order to see when this infernal loop appear.
I have added some trace in the fcc_enet_start_xmit .
has you know, after some kind of transmit errors, the transmitter need to be restarted, and so I have added some traces to see when it is restarted
/* Some transmit errors cause the transmitter to shut
* down. We now issue a restart transmit. Since the
* errors close the BD and update the pointers, the restart
* _should_ pick up without having to reset any of our
* pointers either. Also, To workaround 8260 device erratum
* CPM37, we must disable and then re-enable the transmitter
* following a Late Collision, Underrun, or Retry Limit error.
*/
# UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
UNDERRUN ! ==> RESTART
CARRIER LOST !
........
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f778 tx_free 0 cur_rx c019f690.
Tx @base c019f708 :
1c02 055c 012cd86a
9c00 05ea 012cd06a
9c00 05ea 012f706a
9c00 05ea 012cf06a
9c00 05ea 012cf86a
9c00 05ea 0118506a
Some personns have said me to try with 2.6 drivers but it's exactly the same problem.
( even if I'm a little bit surprised to see that with the 2.6 version drivers seems to be uncompatible with boards wich use MDIO without PHY
interrupt.the #define PHY_INTERRUPT condition of the 2.4 drivers version has
disapeared => with this new drivers you can't use MDIO without PHY interrupt !!
it was possible in the 2.4 version.
- seeing that the "fep->link" value is enabled only on a PHY interrupt .
I can't have this condition OK without PHY interrupt.
"fep->link" can be asserted in the mii_parse_sr function, but has it is
indicated in the comment in the drivers :
"/* Somehow does the 971 tell me that the link is down
* the first read after power-up.
* read here to get a valid value in ack_int */"
That's true, the LXT 971A tell that the link is down, and seeing that I
have no interrupt, the fep->link is never asserted again.
So, I have commented the first lines of the fcc_enet_start_xmit function
which verify the value of fep->link.
I have added a #ifdef PHY_INTERRUPT condition before installing the ISR
for this interrupt.
And thanks to that, I have been able to test the new driver 2.6 .
But unfortunetly this doesn't solve my problem.)
So 2.6 driver is not the solution of my problem.
I'm asking myself if this can be due to CPM21, or CPM22, or CPM119 known bugs on mpc8260 ?
(see http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf <http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf> ) but I don't think so.
Perhaps, I imagine that in fact the MPC8260 transmitter doesn't restart correctly ?
(Also, To workaround 8260 device erratum
* CPM37, we must disable and then re-enable the transmitter
* following a Late Collision, Underrun, or Retry Limit error)
Is there anybody having encounter the same problem?
Is there anybody having done some test of numerous plug/unplug during important data transfert with a half-duplex connection on mpc8260?
Is there anybody having an idea to help me ?
Thanks to the community for any help, I'm really desepareted here
(PS : sorry for my bad english)
[-- Attachment #2: Type: text/html, Size: 9656 bytes --]
^ permalink raw reply
* Re: Re: Enable a PCMCIA Bluetooth card in custom MPC860 system
From: Lo Chun Chung @ 2006-01-10 1:39 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <43C2A6DD.5020202@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 4775 bytes --]
Thanks for your hint. But the file is just for Linux Kernel Version 2.6, is this also OK for me? (I am using a 2.4 kernel)
But I doubt that same technique can be applied since the Bluetooth should only be enabled when I loaded the pcmcia drivers (pcmcia_core.o, m8xx_pcmcia.o and ds.o), so ....
how can I pre-set some settings during boot-time that I have not yet insert the pcmcia modules into the kernel?
Also the last thing is, since there is not "hotplug" in my system and resources allocation is different from standard PCs, so I cannot let my embedded system to auto-detect a standard uart has been added during the PCMCIA bluetooth card is plugged in (while standard PC will)
or can anybody tell me that how can I realize hotplug in my system? (is this can be worked out?)
Thanks
Vitaly Bordug <vbordug@ru.mvista.com> 說：
Lo Chun Chung wrote:
> Dear all,
>
> I am a student from Hong Kong. Now I am doing a project about enabling a
> Bluetooth PCMCIA card (Billionton PCBTC1A-B) in a custom MPC860PC.
>
> (The custom MPC860 system is constructed by a MPC860 Processor Card and
> a custom made PCB to adding a PCMCIA interface to the processor Card.)
>
> Now my stage is: the LINUX (Linux Kernel 2.4.25 from ELDK 3.1 for
> powerpc) can recognise the card by cardctl, and here are the screen dump:
>
> / # cardctl ident
> Socket 0:
> product info: "PCMCIA", "Bluetooth Card", "", ""
> manfid: 0x0279, 0x950b
> function: 2 (serial)
> / # cardctl status
> Socket 0:
> 5V 16-bit PC Card
> function 0: [ready], [bat dead], [bat low]
> / # cardctl info
> PRODID_1="PCMCIA"
> PRODID_2="Bluetooth Card"
> PRODID_3=""
> PRODID_4=""
> MANFID=0279,950b
> FUNCID=2
> / # cardct! l config
> Socket 0:
> Vcc 5.0V Vpp1 5.0V Vpp2 5.0V
>
> but after I load all the modules needed (should be these?)
>
> / # lsmod
> Module Size Used by Not tainted
> hci_uart 14836 0 (unused)
> l2cap 22956 0 (unused)
> bluez 43856 0 [hci_uart l2cap]
> ds 8060 0
> m8xx_pcmcia 5164 1
> pcmcia_core 39520 0 [ds m8xx_pcmcia]
>
> my bluetooth still cannot get working ...
>
> then I try to insert "serial_cs" as my bluetooth card is a uart base
> card. but some message given out:
>
> / # insmod serial_cs
> Using /lib/modules/2.4.25/serial_cs.o
> insmod: unresolved symbol unregister_serial
> insmod: unresolved symbol register_serial
>
> so I realize that I should also insert "serial.o" into the linux, but
> crashes ...
>
> / # insmod serial
> Using /lib/modules/2.4.25/serial.o
> Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ enabled
> Machine check in kernel mode.
> Caused by (from SRR1=1032): Transfer error ack signal
> ! Oops: machine check, sig: 7
> NIP: C3040078 XER: 00000000 LR: C3044724 SP: C1CC1D60 REGS: c1cc1cb0
> TRAP: 0200 No
> t tainted
> MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
> TASK = c1cc0000[33] 'busybox' Last syscall: 128
> last math 00000000 last altivec 00000000
> GPR00: 00000000 C1CC1D60 C1CC0000 C1CC1D70 00000004 00000001 00000B4B
> C015378B
> GPR08: 00000000 800003FC 00000003 C1CC1C70 C0170000 10084438 00000000
> 00000000
> GPR16: 00000000 00000000 00000000 00000000 00009032 1016EDB0 C1D3A000
> C1CC1EA0
> GPR24: C1F6B760 00000006 C304973C C1CC1D70 C3040000 00000000 00000000
> C3046348
> Call backtrace:
> C3044718 C3045188 C0012440 C00043BC 10080000 10021DF0 100238CC
> 1000457C 100041A0 1000436C 1000457C 100041A0 0FE70EF4 00000000
>
> I only knows when i insert the serial.o, this driver will try to access
> the standard uart which is not available in my system (my system only
> has one uart by SMC1), then the system will crash eac! h time the
> driver wants to access the registers does not available ...
>
> The project deadline is near ... so I ask here ...
>
> can anyone helps me or give me some clues?
>
You should take a look for instance how 8349 does this job (arch/ppc/syslib/ppc83xx_setup.c) - it also has "standard" UART, but some stuff needs to be set up
prior to serial.o. Of course that is not complete solution for your case, just a hint...
> Thanks all
>
>
>
>
> Best regards,
> Chung
>
> _______________________________________
> YM - 離線訊息
> 就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何
> 說話都冇走失。
> http://messenger.yahoo.com.hk
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Sincerely,
Vitaly
Best regards,
Chung
_______________________________________
YM - 離線訊息
就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何說話都冇走失。
http://messenger.yahoo.com.hk
[-- Attachment #2: Type: text/html, Size: 5766 bytes --]
^ permalink raw reply
* Re: RESEND:Problems starting /init
From: Shawn Jin @ 2006-01-09 18:45 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <43BC57E7.40408@dlasys.net>
> But I can not get busybox to output a thing either run as /init o=
r run
> as /bin/sh.
>
> I have aslo tried /bin/sash - no output.
> I have even cross compiled sash - with all kinds of "I am here"
> debugging scattered through main(), If I runn it on a powerbook, I get
> what I expect. If I run it as /bin/sh on the e12 I get no output.
>
>
> Does anyone even have any ideas what I can look at ?
Another thing you may try is to make sure the UART works correctly
with interrupt mode. So set some breakpoints in UART's IRS to see what
happens.
Regards,
-Shawn.
^ permalink raw reply
* Re: Enable a PCMCIA Bluetooth card in custom MPC860 system
From: Vitaly Bordug @ 2006-01-09 18:09 UTC (permalink / raw)
To: Lo Chun Chung; +Cc: linuxppc-embedded
In-Reply-To: <20060109164942.62300.qmail@web53713.mail.yahoo.com>
Lo Chun Chung wrote:
> Dear all,
>
> I am a student from Hong Kong. Now I am doing a project about enabling a
> Bluetooth PCMCIA card (Billionton PCBTC1A-B) in a custom MPC860PC.
>
> (The custom MPC860 system is constructed by a MPC860 Processor Card and
> a custom made PCB to adding a PCMCIA interface to the processor Card.)
>
> Now my stage is: the LINUX (Linux Kernel 2.4.25 from ELDK 3.1 for
> powerpc) can recognise the card by cardctl, and here are the screen dump:
>
> / # cardctl ident
> Socket 0:
> product info: "PCMCIA", "Bluetooth Card", "", ""
> manfid: 0x0279, 0x950b
> function: 2 (serial)
> / # cardctl status
> Socket 0:
> 5V 16-bit PC Card
> function 0: [ready], [bat dead], [bat low]
> / # cardctl info
> PRODID_1="PCMCIA"
> PRODID_2="Bluetooth Card"
> PRODID_3=""
> PRODID_4=""
> MANFID=0279,950b
> FUNCID=2
> / # cardct! l config
> Socket 0:
> Vcc 5.0V Vpp1 5.0V Vpp2 5.0V
>
> but after I load all the modules needed (should be these?)
>
> / # lsmod
> Module Size Used by Not tainted
> hci_uart 14836 0 (unused)
> l2cap 22956 0 (unused)
> bluez 43856 0 [hci_uart l2cap]
> ds 8060 0
> m8xx_pcmcia 5164 1
> pcmcia_core 39520 0 [ds m8xx_pcmcia]
>
> my bluetooth still cannot get working ...
>
> then I try to insert "serial_cs" as my bluetooth card is a uart base
> card. but some message given out:
>
> / # insmod serial_cs
> Using /lib/modules/2.4.25/serial_cs.o
> insmod: unresolved symbol unregister_serial
> insmod: unresolved symbol register_serial
>
> so I realize that I should also insert "serial.o" into the linux, but
> crashes ...
>
> / # insmod serial
> Using /lib/modules/2.4.25/serial.o
> Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ enabled
> Machine check in kernel mode.
> Caused by (from SRR1=1032): Transfer error ack signal
> ! Oops: machine check, sig: 7
> NIP: C3040078 XER: 00000000 LR: C3044724 SP: C1CC1D60 REGS: c1cc1cb0
> TRAP: 0200 No
> t tainted
> MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
> TASK = c1cc0000[33] 'busybox' Last syscall: 128
> last math 00000000 last altivec 00000000
> GPR00: 00000000 C1CC1D60 C1CC0000 C1CC1D70 00000004 00000001 00000B4B
> C015378B
> GPR08: 00000000 800003FC 00000003 C1CC1C70 C0170000 10084438 00000000
> 00000000
> GPR16: 00000000 00000000 00000000 00000000 00009032 1016EDB0 C1D3A000
> C1CC1EA0
> GPR24: C1F6B760 00000006 C304973C C1CC1D70 C3040000 00000000 00000000
> C3046348
> Call backtrace:
> C3044718 C3045188 C0012440 C00043BC 10080000 10021DF0 100238CC
> 1000457C 100041A0 1000436C 1000457C 100041A0 0FE70EF4 00000000
>
> I only knows when i insert the serial.o, this driver will try to access
> the standard uart which is not available in my system (my system only
> has one uart by SMC1), then the system will crash eac! h time the
> driver wants to access the registers does not available ...
>
> The project deadline is near ... so I ask here ...
>
> can anyone helps me or give me some clues?
>
You should take a look for instance how 8349 does this job (arch/ppc/syslib/ppc83xx_setup.c) - it also has "standard" UART, but some stuff needs to be set up
prior to serial.o. Of course that is not complete solution for your case, just a hint...
> Thanks all
>
>
>
>
> Best regards,
> Chung
>
> _______________________________________
> YM - 離線訊息
> 就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何
> 說話都冇走失。
> http://messenger.yahoo.com.hk
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Sincerely,
Vitaly
^ permalink raw reply
* mpc8260 fcc enet transmit time out
From: hubert.loewenguth @ 2006-01-09 17:27 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 5321 bytes --]
hi the community.
I have already posted a question about my problem but it seems that
nobody has encounter the same matter.
So I have made numerous tests and researches and seeing that I still
have not succeed in solving it, I try again tyo send you my bug.
I use a MPC8260 with linux 2.4.20.
The problem is with the fcc_enet driver.
I have no MII phy interrupt line with my LXT971 Phy in front of the powerpc.
Seeing that I have no interrupt line, I have configured the driver to be
in half duplex, and the LXT971 too.
I'm sure that the driver is in half-duplex mode an the LXT971 too, and
the auto-negociation is ok.
Everything works fine, but, if I do successive plugs/unplugs during
important data transfert, The driver enter into an infinite loop:
/# NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f690.
Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
...
1c00 055c 011d486a
3c00 05ea 011d406a
Rx @base c019f608 :
9c00 0040 01f3e000
9c00 0040 01f3e800
...
9c00 0040 01f3d000
bc00 0040 01f2f800
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f748 tx_free 0 cur_rx c019f698.
Tx @base c019f708 :
1c00 055c 011cd06a
5c00 003b 011cd86a
1c00 05ea 011ce06a
.....
/I have found, on the linux-embended forum, a personn who has the same
problem:
http://ozlabs.org/pipermail/linuxppc-embedded/2001-December/005714.html
But I'm sure about my pin connections ans so the reponse to this personn
doesn't solve my problem
More interresting this one :
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016539.html
This personn seems to have the same troubleshouting than me .
He has tried to apply the patch provided by freescale, but it doesn't
seem to correct it.
/
/So I have had just a little piece of trace in order to see when this
infernal loop appear.
I have added some trace in the fcc_enet_start_xmit .
has you know, after some kind of transmit errors, the transmitter need
to be restarted, and so I have added some traces to see when it is restarted
/* Some transmit errors cause the transmitter to shut
* down. We now issue a restart transmit. Since the
* errors close the BD and update the pointers, the restart
* _should_ pick up without having to reset any of our
* pointers either. Also, To workaround 8260 device erratum
* CPM37, we must disable and then re-enable the transmitter
* following a Late Collision, Underrun, or Retry Limit error.
*/
# UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
UNDERRUN ! ==> RESTART
CARRIER LOST !
........
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
CARRIER LOST !
UNDERRUN ! ==> RESTART
/
N/ETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx c019f778 tx_free 0 cur_rx c019f690.
Tx @base c019f708 :
1c02 055c 012cd86a
9c00 05ea 012cd06a
9c00 05ea 012f706a
9c00 05ea 012cf06a
9c00 05ea 012cf86a
9c00 05ea 0118506a
/
/Some personns have said me to try with 2.6 drivers but it's exactly the
same problem.
( even if I'm a little bit surprised to see that with the 2.6 version
drivers seems to be uncompatible with boards wich use MDIO without PHY
interrupt.the #define PHY_INTERRUPT condition of the 2.4 drivers version has
disapeared => with this new drivers you can't use MDIO without PHY
interrupt !!
it was possible in the 2.4 version.
- seeing that the "fep->link" value is enabled only on a PHY interrupt .
I can't have this condition OK without PHY interrupt.
"fep->link" can be asserted in the mii_parse_sr function, but has it is
indicated in the comment in the drivers :
"/* Somehow does the 971 tell me that the link is down
* the first read after power-up.
* read here to get a valid value in ack_int */"
That's true, the LXT 971A tell that the link is down, and seeing that I
have no interrupt, the fep->link is never asserted again.
So, I have commented the first lines of the fcc_enet_start_xmit function
which verify the value of fep->link.
I have added a #ifdef PHY_INTERRUPT condition before installing the ISR
for this interrupt.
And thanks to that, I have been able to test the new driver 2.6 .
But unfortunetly this doesn't solve my problem.)
So 2.6 driver is not the solution of my problem.
I'm asking myself if this can be due to CPM21, or CPM22, or CPM119 known
bugs on mpc8260 ?
(see http://www.freescale.com/files/32bit/doc/data_sheet/MPC8260CE.pdf )
but I don't think so.
Perhaps, I imagine that in fact the MPC8260 transmitter doesn't restart
correctly ?
(Also, To workaround 8260 device erratum
* CPM37, we must disable and then re-enable the transmitter
* following a Late Collision, Underrun, or Retry Limit error)
Is there anybody having encounter the same problem?
Is there anybody having done some test of numerous plug/unplug during
important data transfert with a half-duplex connection on mpc8260?
Is there anybody having an idea to help me ?
Thanks to the community for any help, I'm really desepareted here
(PS : sorry for my bad english)
[-- Attachment #2: Type: text/html, Size: 7298 bytes --]
^ permalink raw reply
* Enable PCMCIA Bluetooth in a custom MPC860 system
From: Lo Chun Chung @ 2006-01-09 16:58 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3165 bytes --]
Dear all,
I am a student from Hong Kong. Now I am doing a project about enabling a Bluetooth PCMCIA card (Billionton PCBTC1A-B) in a custom MPC860PC.
(The custom MPC860 system is constructed by a MPC860 Processor Card and a custom made PCB to adding a PCMCIA interface to the processor Card.)
Now my stage is: the LINUX (Linux Kernel 2.4.25 from ELDK 3.1 for powerpc) can recognise the card by cardctl, and here are the screen dump:
/ # cardctl ident
Socket 0:
product info: "PCMCIA", "Bluetooth Card", "", ""
manfid: 0x0279, 0x950b
function: 2 (serial)
/ # cardctl status
Socket 0:
5V 16-bit PC Card
function 0: [ready], [bat dead], [bat low]
/ # cardctl info
PRODID_1="PCMCIA"
PRODID_2="Bluetooth Card"
PRODID_3=""
PRODID_4=""
MANFID=0279,950b
FUNCID=2
/ # cardctl config
Socket 0:
Vcc 5.0V Vpp1 5.0V Vpp2 5.0V
but after I load all the modules needed (should be these?)
/ # lsmod
Module Size Used by Not tainted
hci_uart 14836 0 (unused)
l2cap 22956 0 (unused)
bluez 43856 0 [hci_uart l2cap]
ds 8060 0
m8xx_pcmcia 5164 1
pcmcia_core 39520 0 [ds m8xx_pcmcia]
my bluetooth still cannot get working ...
then I try to insert "serial_cs" as my bluetooth card is a uart base card. but some message given out:
/ # insmod serial_cs
Using /lib/modules/2.4.25/serial_cs.o
insmod: unresolved symbol unregister_serial
insmod: unresolved symbol register_serial
so I realize that I should also insert "serial.o" into the linux, but crashes ...
/ # insmod serial
Using /lib/modules/2.4.25/serial.o
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ enabled
Machine check in kernel mode.
Caused by (from SRR1=1032): Transfer error ack signal
Oops: machine check, sig: 7
NIP: C3040078 XER: 00000000 LR: C3044724 SP: C1CC1D60 REGS: c1cc1cb0 TRAP: 0200 No
t tainted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c1cc0000[33] 'busybox' Last syscall: 128
last math 00000000 last altivec 00000000
GPR00: 00000000 C1CC1D60 C1CC0000 C1CC1D70 00000004 00000001 00000B4B C015378B
GPR08: 00000000 800003FC 00000003 C1CC1C70 C0170000 10084438 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00009032 1016EDB0 C1D3A000 C1CC1EA0
GPR24: C1F6B760 00000006 C304973C C1CC1D70 C3040000 00000000 00000000 C3046348
Call backtrace:
C3044718 C3045188 C0012440 C00043BC 10080000 10021DF0 100238CC
1000457C 100041A0 1000436C 1000457C 100041A0 0FE70EF4 00000000
I only knows when i insert the serial.o, this driver will try to access the standard uart which is not available in my system (my system only has one uart by SMC1), then the system will crash each time the driver wants to access the registers does not available ...
The project deadline is near ... so I ask here ...
can anyone helps me or give me some clues?
Thanks all
Best regards,
Chung
_______________________________________
YM - 離線訊息
就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何說話都冇走失。
http://messenger.yahoo.com.hk
[-- Attachment #2: Type: text/html, Size: 4437 bytes --]
^ permalink raw reply
* Enable a PCMCIA Bluetooth card in custom MPC860 system
From: Lo Chun Chung @ 2006-01-09 16:49 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3170 bytes --]
Dear all,
I am a student from Hong Kong. Now I am doing a project about enabling a Bluetooth PCMCIA card (Billionton PCBTC1A-B) in a custom MPC860PC.
(The custom MPC860 system is constructed by a MPC860 Processor Card and a custom made PCB to adding a PCMCIA interface to the processor Card.)
Now my stage is: the LINUX (Linux Kernel 2.4.25 from ELDK 3.1 for powerpc) can recognise the card by cardctl, and here are the screen dump:
/ # cardctl ident
Socket 0:
product info: "PCMCIA", "Bluetooth Card", "", ""
manfid: 0x0279, 0x950b
function: 2 (serial)
/ # cardctl status
Socket 0:
5V 16-bit PC Card
function 0: [ready], [bat dead], [bat low]
/ # cardctl info
PRODID_1="PCMCIA"
PRODID_2="Bluetooth Card"
PRODID_3=""
PRODID_4=""
MANFID=0279,950b
FUNCID=2
/ # cardctl config
Socket 0:
Vcc 5.0V Vpp1 5.0V Vpp2 5.0V
but after I load all the modules needed (should be these?)
/ # lsmod
Module Size Used by Not tainted
hci_uart 14836 0 (unused)
l2cap 22956 0 (unused)
bluez 43856 0 [hci_uart l2cap]
ds 8060 0
m8xx_pcmcia 5164 1
pcmcia_core 39520 0 [ds m8xx_pcmcia]
my bluetooth still cannot get working ...
then I try to insert "serial_cs" as my bluetooth card is a uart base card. but some message given out:
/ # insmod serial_cs
Using /lib/modules/2.4.25/serial_cs.o
insmod: unresolved symbol unregister_serial
insmod: unresolved symbol register_serial
so I realize that I should also insert "serial.o" into the linux, but crashes ...
/ # insmod serial
Using /lib/modules/2.4.25/serial.o
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ enabled
Machine check in kernel mode.
Caused by (from SRR1=1032): Transfer error ack signal
Oops: machine check, sig: 7
NIP: C3040078 XER: 00000000 LR: C3044724 SP: C1CC1D60 REGS: c1cc1cb0 TRAP: 0200 No
t tainted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c1cc0000[33] 'busybox' Last syscall: 128
last math 00000000 last altivec 00000000
GPR00: 00000000 C1CC1D60 C1CC0000 C1CC1D70 00000004 00000001 00000B4B C015378B
GPR08: 00000000 800003FC 00000003 C1CC1C70 C0170000 10084438 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00009032 1016EDB0 C1D3A000 C1CC1EA0
GPR24: C1F6B760 00000006 C304973C C1CC1D70 C3040000 00000000 00000000 C3046348
Call backtrace:
C3044718 C3045188 C0012440 C00043BC 10080000 10021DF0 100238CC
1000457C 100041A0 1000436C 1000457C 100041A0 0FE70EF4 00000000
I only knows when i insert the serial.o, this driver will try to access the standard uart which is not available in my system (my system only has one uart by SMC1), then the system will crash each time the driver wants to access the registers does not available ...
The project deadline is near ... so I ask here ...
can anyone helps me or give me some clues?
Thanks all
Best regards,
Chung
_______________________________________
YM - 離線訊息
就算你沒有上網，你的朋友仍可以留下訊息給你，當你上網時就能立即看到，任何說話都冇走失。
http://messenger.yahoo.com.hk
[-- Attachment #2: Type: text/html, Size: 4448 bytes --]
^ permalink raw reply
* Re: Booting from RAM Disk
From: Grant Likely @ 2006-01-09 16:50 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: Linuxppc-embedded
In-Reply-To: <43C027B0.2070409@dlasys.net>
David H. Lynch Jr. wrote:
> Grant Likely wrote:
>
> I have never tried to build an initrd system.
rolling up an initrd & kernel is actually very simple; but I had to read
the Makefile to figure out how to do it! I do it by copying
ramdisk.image.gz into arch/ppc/boot/images and building 'make
zImage.initrd'.
>
> I like initramfs - the only problem I had putting it together was
> finding the information to do it.
>
> In the instance of the E12 I needed something that was wrapped into a
> single file with the kernl. The E12 already had an elf loader, but all
> it did was load elf files. It did not handle ramdisk other images etc.
> INITRAMFS provided a means to start on the E12 without having to write
> another loader.
So... how do you build the initramfs?
I'd prefer to use initramfs; I just haven't had a whole lot of luck with
it and other concerns took my focus. :/
Thanks,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Help with installing 2.6 kernel on Rattler PCI 8250
From: Sondre Garsjø @ 2006-01-09 14:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060109123937.C101868A4D@ozlabs.org>
Hi,
I am installing the 2.6 kernel on my 8250. I have tried a few
different versions, but none of them have any rattler-config, or
rattler-option in the platform-options of menuconfig. If anyone has any
recommendations on which kernel version to use and info on any
patches or configs for a rattler-card this would be highly appreciated.
I'm really stuck here without a clue...
Thanks,
Sondre
^ permalink raw reply
* help needed:relocation truncated to fit: R_PPC_REL24 _init
From: zengshuai @ 2006-01-09 13:31 UTC (permalink / raw)
To: ppc
detail:
ppc_6xx-gcc ../../../../lib/EmbedCLib/OBJ/link.x -Wall ../../../../lib/EmbedCLi
/OBJ/gcc_crt1.o -Wl,-Ttext -Wl,0x4000 -Wl,-defsym -Wl,STACK_START=0x400000 -Wl
-defsym -Wl,STACK_END=0x300000 -o aal25 ./OBJ_ATM/mm.o ./OBJ_ATM/mem_alloc.o .
OBJ_ATM/mem.o ./OBJ_ATM/cell.o ./OBJ_ATM/buffer.o ./OBJ_ATM/frame.o ./OBJ_ATM/s
f.o ./OBJ_ATM/ll.o ./OBJ_ATM/cq.o ./OBJ_ATM/Pq2Cpm_ci.o ./OBJ_ATM/Pq2Cpm.o ./OB
_ATM/PQII_ci.o ./OBJ_ATM/PQII.o ./OBJ_ATM/atm_bdm.o ./OBJ_ATM/fbp.o ./OBJ_ATM/r
.o ./OBJ_ATM/atm_fcc_ci.o ./OBJ_ATM/atm_chan_ci.o ./OBJ_ATM/atm_pm_ci.o ./OBJ_A
M/aal5_ci.o ./OBJ_ATM/rct.o ./OBJ_ATM/tct.o ./OBJ_ATM/vpt_vct.o ./OBJ_ATM/bd.o
/OBJ_ATM/atm_fcc.o ./OBJ_ATM/atm_chan.o ./OBJ_ATM/atm_pm.o ./OBJ_ATM/atm_demo.o
./OBJ_ATM/xx.o ./OBJ_ATM/atm_phy.o ./OBJ_ATM/intrPQII.o ./OBJ_ATM/aal0_ci.o ./
BJ_ATM/aal0.o ./OBJ_ATM/aal2_ci.o ./OBJ_ATM/aal2.o ./OBJ_ATM/aal5.o ./OBJ_ATM/A
L25.o -L../../../../lib/EmbedCLib/OBJ -lembc_gcc
../../../../lib/EmbedCLib/OBJ/gcc_crt1.o(.text+0x0): multiple definition of `_s
art'
/opt/eldk3/usr/../ppc_6xx/usr/lib/crt1.o(.text+0x0): first defined here
/opt/eldk3/usr/bin/../lib/gcc-lib/ppc-linux/3.3.3/../../../../ppc-linux/bin/ld:
Warning: type of symbol `_start' changed from 2 to 1 in ../../../../lib/EmbedCL
b/OBJ/gcc_crt1.o
../../../../lib/EmbedCLib/OBJ/libembc_gcc.a(init.o)(.text+0x0): In function `_i
it':
: multiple definition of `_init'
/opt/eldk3/usr/../ppc_6xx/usr/lib/crti.o(.init+0x0): first defined here
../../../../lib/EmbedCLib/OBJ/libembc_gcc.a(init.o)(.text+0x56): In function `_
nit':
: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead
/opt/eldk3/usr/../ppc_6xx/usr/lib/crti.o(.init+0xc): In function `_init':
: relocation truncated to fit: R_PPC_LOCAL24PC .text
/opt/eldk3/usr/bin/../lib/gcc-lib/ppc-linux/3.3.3/m603/crtbegin.o(.init+0x0): r
../../../../lib/EmbedCLib/OBJ/gcc_crt1.o(.text+0x1c): relocation truncated to f
t: R_PPC_REL24 _init
/opt/eldk3/usr/../ppc_6xx/usr/lib/libc_nonshared.a(elf-init.oS)(.text+0x18): In
function `__libc_csu_init':
: relocation truncated to fit: R_PPC_REL24 _init
/opt/eldk3/usr/bin/../lib/gcc-lib/ppc-linux/3.3.3/m603/crtend.o(.init+0x0): rel
cation truncated to fit: R_PPC_REL24 .text
collect2: ld returned 1 exit status
gmake[1]: *** [aal25] Error 1
gmake[1]: Leaving directory `/home/test2-td/NetCommSw/PQII/demos/AtmDemos'
gmake: *** [AAL25] Error 2
There was same errors,when I link another program,which was very sample.
Later,I replaced the ppc_6xx-gcc with ppc_6xx-ld to link,and succeed.
But that was a very sample program,which didn't need libc.a and so on.
What is "relocation truncated to fit: R_PPC_REL24 _init"? How to fix it? thanks
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
^ permalink raw reply
* Re: Badness in dma_alloc_init
From: Kalle Pokki @ 2006-01-09 13:35 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <20060109125339.GA12997@oops.ghostprotocols.net>
Aristeu Sergio Rozanski Filho wrote:
>Hi!
>
>
>>I'm having some trouble with the DMA allocation using Linux 2.6.14-rc2 +
>>some platform modifications. Namely, the dma_alloc_coherent() function
>>returns bogus virtual addresses causing machine check exceptions. At
>>boot, the kernel complains there is something wrong, but I cannot figure
>>out how to fix it. CONFIG_CONSISTENT_START is at its default value,
>>0xff100000. Any hints where to look further?
>>
>>Oh, this is a custom 8xx board. Has the support for DMA in 8xx been
>>unstable at the time of pre-2.6.14?
>>
>>
>probably your IMAP_ADDR is at 0xff000000, isn't it? if it is, please adjust
>CONFIG_CONSISTENT_START to an address like 0xe0000000.
>
>
>
True, my IMAP_ADDR is at 0xff000000. But IMAP_SIZE is just 64 KB, so
there should be no overlap, right? Or is the IMAP memory area mapped
with an 8-MB TLB entry or something like that?
No badness in dma-mapping.c anymore with CONFIG_CONSISTENT_START being
0xe0000000, however. Thanks.
^ permalink raw reply
* Re: Badness in dma_alloc_init
From: Aristeu Sergio Rozanski Filho @ 2006-01-09 12:53 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <43C25787.4010204@iki.fi>
Hi!
> I'm having some trouble with the DMA allocation using Linux 2.6.14-rc2 +
> some platform modifications. Namely, the dma_alloc_coherent() function
> returns bogus virtual addresses causing machine check exceptions. At
> boot, the kernel complains there is something wrong, but I cannot figure
> out how to fix it. CONFIG_CONSISTENT_START is at its default value,
> 0xff100000. Any hints where to look further?
>
> Oh, this is a custom 8xx board. Has the support for DMA in 8xx been
> unstable at the time of pre-2.6.14?
probably your IMAP_ADDR is at 0xff000000, isn't it? if it is, please adjust
CONFIG_CONSISTENT_START to an address like 0xe0000000.
--
Aristeu
^ permalink raw reply
* Re: VFS: Cannot open root device "31:03" or unknown-block(31,3)
From: Wolfgang Denk @ 2006-01-09 13:05 UTC (permalink / raw)
To: David Jander; +Cc: HappyPhot, linuxppc-embedded
In-Reply-To: <200601090945.22564.david.jander@protonic.nl>
In message <200601090945.22564.david.jander@protonic.nl> you wrote:
>
> ELDK-3.1.1 has a glibc compiled with support of a certain version of the
> kernel (I guess it's 2.4.xx), so newer kernels might run (because they are
They do run.
> obviously backwards compatible), but some features of 2.6 cannot be used
> (e.g. support for the latest syscalls, different HZ, etc...)
You can also change HZ if you like.
> A second issue is the boot procedure. If you are a beginner with linux, you'd
> probably start booting from NFS root as it gets installed in the ELDK/ppc_xxx
> directory. That probably won't work very well with latest 2.6 kernels (device
> files missing, sysfs not mounted, shmfs has different name, etc...)
You can (mis-) configre a 2.4 kernel too. Using a sane kernel
configuration ther ewill be no problems. We have been using ELDK
3.1.1 for a long time ourself developing 2.6 kernel code.
> > C++ programs and with any version of the kernel tree (at least in
> > theory; very recent version s of the Linux kernel [ > 2.6.14] cannot
> > be compiled with ELDK 3.1.x any more, but this is a different issue).
>
> See what I mean? HappyPhot did just that: compile 2.6.14.2 with ELDK 3.1.1!!!
I wrote "> 2.6.14"; 2.6.14.2 is just a branch off 2.6.14 and is fine
AFAICT.
> > The ELDK supports *any* kernel version.
>
> Ok, let's talk about "recommended" kernel then. I would never recommend
There is no recommended kernel version. On contrary, we take great
efforts to keep the ELDK independent of speicfic kernelk versions as
far as possible.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Quantum particles: The dreams that stuff is made of.
^ permalink raw reply
* Badness in dma_alloc_init
From: Kalle Pokki @ 2006-01-09 12:31 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm having some trouble with the DMA allocation using Linux 2.6.14-rc2 +
some platform modifications. Namely, the dma_alloc_coherent() function
returns bogus virtual addresses causing machine check exceptions. At
boot, the kernel complains there is something wrong, but I cannot figure
out how to fix it. CONFIG_CONSISTENT_START is at its default value,
0xff100000. Any hints where to look further?
Oh, this is a custom 8xx board. Has the support for DMA in 8xx been
unstable at the time of pre-2.6.14?
Linux version 2.6.14-rc2 (kp@host32.eke.fi) (gcc version 4.0.0 (DENX
ELDK 4.0 4.
0.0)) #1 Mon Jan 9 12:53:41 EET 2006
Built 1 zonelists
Kernel command line: root=/dev/mtdblock1 ro console=ttyCPM0,115200
PID hash table entries: 256 (order: 8, 4096 bytes)
Decrementer Frequency = 247500000/60
Console: colour dummy device 80x25
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 30268k available (1608k kernel code, 376k data, 100k init, 0k
highmem)
Mount-cache hash table entries: 512
Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:348
Call trace: [c0003670] [c0003f24] [c0003320] [c01e2ad0] [c000228c]
[c000551
c]
... followed by otherwise good startup.
^ permalink raw reply
* Re: io.h question
From: Arnd Bergmann @ 2006-01-09 12:39 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D042A2F4E@rennsmail02.eu.thmulti.com>
On Monday 09 January 2006 12:16, Fillod Stephane wrote:
> You may not include the file directly from a user-land application
> program, but you may copy/paste the in_*/out_* macros, with appropriate
> care off course.
Yes, that happens to work on some architectures, but it makes your program
not portable. Also, on some architectures you need special privileges,
e.g. i386 requires you to call iopl() first.
> >The correct way to solve your problem (which you did not explain, so
> >I can only guess) would be to write a kernel device driver for
> >the peripherial you want to drive, at least if it does not exist yet.
>
> Sometimes, user-land access can make things simpler. YMMV.
Yes, that's true. I that's why I said I was only guessing ;-).
But even if I want to do the access from user space, I would
normally write a small device driver that exposes the registers
as an mmappable character device.
> >For prototyping, you can play with mmap() on /dev/mem in a user
> >application, but that is often not very reliable.
>
> For sake of curiosity, what is not reliable in mmap'ed access
> by user application?
- Depending on your device, you may not be able to guarantee the
correct timing for accessing the device.
- Some devices require locking to ensure you are accessing the
registers in the right order. This breaks if you accidentally
run your user space program more than once at a time.
- If the hardware changes with a later revision, you need to change
your user space programs. Such changes ought to be hidden in the
kernel.
- If your program is buggy, you might end up writing to a different
device or memory location, which is very hard to debug.
Arnd <><
^ permalink raw reply
* RE: io.h question
From: Fillod Stephane @ 2006-01-09 12:16 UTC (permalink / raw)
To: linuxppc-embedded, Arnd Bergmann
Arnd Bergmann wrote:
>On Thursday 05 January 2006 21:00, mcnernbm@notes.udayton.edu wrote:
>> I finally noticed out_8 and in_8 and what not are located in the
>> ppc io.h file in the kernel development download.=A0 But when I=20
>> tried to do a io.h with in my program I added #include <asm/io.h>=A0
>> and it seems to find it with not problems but it can not find the
>> functions with in that file.=A0 Am i missing a define I need to set
>> or something so I can see the right files with in io.h I am
>> compiling for a ppc405 on a xilinx virtex 4 board. =20
>
>The definitions in that file are only usable from inside the kernel,
>you can not use them in a user space application.
You may not include the file directly from a user-land application
program, but you may copy/paste the in_*/out_* macros, with appropriate=20
care off course.
>The correct way to solve your problem (which you did not explain, so
>I can only guess) would be to write a kernel device driver for
>the peripherial you want to drive, at least if it does not exist yet.
Sometimes, user-land access can make things simpler. YMMV.
>For prototyping, you can play with mmap() on /dev/mem in a user
>application, but that is often not very reliable.
For sake of curiosity, what is not reliable in mmap'ed access
by user application?
Regards,
--=20
Stephane
^ permalink raw reply
* Re: RESEND:[RFC] Pico E12 (Xilinx V4) patches to 2.6.15
From: David H. Lynch Jr. @ 2006-01-07 6:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <43BF0736.4050703@secretlab.ca>
I have cut out most of the patch and embedded my responses to your
comments. I appreciate your input and will try to get things cleaned up.
I solved what I believe was my last critical porting issue, and now
have Linux on the E12 booting into sash.
Pico has what they need for the moment, and I have two other projects
to get to. But I would like to submit what I have that might be useful
to others.
As I see this it breaks into several major items:
Xilinx UartLite support compliant with the 2.6 serial driver model. I
can break that into a separate patch. I can disable the debugging -
though I would prefer not to remove the code yet.
Should I divide out the early boot part - uartlite_dbg.c and
uartlite_tty.c from the final serial driver ? I see them as belonging
together. There are very few serial devices that have boot to bash
serial support. As soon as I can figure out how to create a selective
patch I can do that. Does the UartLite stuff get submitted here or is
the a preferred place for Serial drivers ? The Uartlite is exclusively a
Xilinx item, and almost exclusively a ppc item (you can put one on a
MicroBlaze).
Minimal Virtex-IV support. I see this as less important, you as well as
other seem to be doing it. Pico has what they need and I will conform it
to whatever makes its way into the kernel later. I would be happy to
submit it, but there probably should be only one set of V4 code, and due
to the constraints of the E12 I have an extremely minimal V4
implimentation. Also this is my first Linux port. The rest of you know
more about what you are doing.
E12 support. Both I an Pico are glad to hear that there is even minimal
interest in including the E12 in the distribution kernel. But at the
moment Pico's clients will likely get support directly. Aside from the
benefits to my ego, the immediate value is to people doing other ports.
Benefits to Pico are long term not short term. The E12 is the first (and
smallest) of a family of devices. Right now this port is E12 specific,
but it is my expectation that it will become a generic Pico port - they
all have keyhole ports, they all use Virtex IV's.
Grant Likely wrote:
> David H. Lynch Jr. wrote:
> Your right; git uses unified by default. You'll need to start reading
> them. If found *lots* of stuff in this patch that shouldn't be there.
I sort of expected that. I am used to other version controll systems,
such as cvs, subversion, sourcesafe, vault, ... where you can commit
what you want when you want, add in lots of personal or temporary
debugging changes, and then clean the out and still eaisly go back and
get them when you want.
The model for git and I suspect bitkeeper, and kernel development in
general is completely different. I think I understand basically how git
works, but that is not the same as completely trusting that I understand
how it works.
>>There are basically 5 parts, and I have no idea how to easily separate
>>the pieces:
>
> Commit to your git tree frequently and commit related files at the same
> time. Then you can bring up a list of all your commits and coalate
> related changes into a single patch.
I appreciate the need to separate the functionality into discrete
patches. The issue - besides learning how to do that is that it does not
correspond to the way things have developed. As an example, I have been
tracing down a problem executing /init (or any initial shell).
At first I thought it was a console output problem - attempting to
isolate that resulted in the addition of an enormous amount of debugging
to the serial driver(2). hen I decided the problem had to be elsewhere
so I started adding debugging into various sys_calls - more to figure
out where I was going than anything else. Then I found I could turn on
SHOW_SYSCALLS, that lead to more debugging in the functions closet to
the actual failure, The problem turned out to be overwriting the
temporary debug IO TLB entry, and not switching to using the virtual
address created by ioremap. So now I have all this debugging all over
the place - mostly turned off. I understand that nobody wants all that
in the kernel, but although I do not need it right now, until I am
comfortable enough with git to know I can save it, blow it away and
retreive it again later, I am not ready to part with it.
Regardless, the bottom line is that I need to get more proficient with
git - I think I learn fairly fast, but there is alot to digest.
My apologies for having to digest that massive diff.
>
> BTW, many of the long lines were word wrapped (making an unusable
> patch). You should attach the diff instead of pasting it into thunderbird.
I thought I did. But I have computer issues at the moment. My primary
development laptop died. My backup laptop started dying, and I am now
working on a desktop that I just built a week ago. I have re-installed
thunderbird and firefox, and linux, and windows (I have paying windows
clients) too many times over the past month. I thought I migrated my
thunderbird profile correctly, but I keep noticing that attachements end
up either inline or separate seemingly at random.
It would be really nice if I could spend alot less time working on
equipemnt and more on programming. I have to get back to a laptop anyway
- or get bifocals, but I am trying to pretend I am not old enough to
need them yet.
>> prompt "Processor Type"
>>- default 6xx
>>+ default 4xx
>
> You don't want to do this... Your defconfig file should set it instead.
I only just recently saw some info on utilizing defconfig files - I
beleive in another of your posts. One of the problems with not knowing
how others do things is that you re-invent the wheel.
Regardles, I do understand.
Figure out how to break the patches up into logical peices.
Figure out how to exclude what are essentially private convenience or
debugging changes from submitted patches.
>>+#ifdef CONFIG_XILINX_UARTLITE_CONSOLE
>>+#LIBS += $(TOPDIR)/drivers/char/xilinx_uartlite/xuartlite_l.o
>>+#endif
>>+# ifeq ($(CONFIG_XILINX_ML300),y)
>>+# CFLAGS_xuartlite_tty.o += -I$(TOPDIR)/drivers/char/xilinx_uartlite
>>+# EXTRA_CFLAGS += -I$(TOPDIR)/arch/ppc/platforms/xilinx_ocp \
>>+# -I$(TOPDIR)/drivers/i2c/xilinx_iic
>>+# endif
>
>
> Wrong place for this; should be done in:
> drivers/char/xilinx_uartlite/Makefile
Actually it is commented out and does not belong at all. I breifly
toyed with trying to port the xilinx 2.4 serial drivers to 2.6, and this
represents an early attempt at merging them into the 2.6 tree.
I am still learning proficiency with the configuration/makefile language
of kernel building, and this was an early attempt to migrate the 2.4 stuff.
At present I am not using the Xilinx UartLite driver. I have a newer
one of my own that was in this patch, and as of a few days ago it
appears to be working.
>> start_:
>>+#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_PICO_E12) /* PPC
>>errata 213: only for Virtex-4 */
>>+ mfccr0 0
>>+ oris 0,0,0x50000000@h
>>+ mtccr0 0
>>+#endif
>
>
> ML300 doesn't have this issue.
I don't have an ML300 or any other Xilinx development board. I borrowed
this from somebody else's code for the ML300.
I am assuming this should change to defined(CONFIG_VIRTEX_IV) ?
>>+static int MillisecTimeout=1000;
>>+void usleep(int t) {
>>+ int ii, waitTime=100;
>>+ while(t) {
>>+ for (ii=0; ii < MillisecTimeout*1000/waitTime; ii++){};
>>+ t--;
>>+ }
>>+}
>
>
> umm, isn't udelay already defined in the kernel?
Probably is, and I probably should be using it, but I started with
working code to write to the device standalone, and incorporated it into
the driver. The same code is repeated in the boot serial code - but
there I do not have access to kernel resources.
>>@@ -180,11 +192,16 @@ load_kernel(unsigned long load_addr, int
>> #ifdef CONFIG_CMDLINE_BOOL
>> memcpy (cmd_line, compiled_string, sizeof(compiled_string));
>> #else
>>+// INITRAMFS and initrd should be handled the same.
>>+#ifdef CONFIG_INITRAMFS_SOURCE
>>+ memcpy (cmd_line, ramroot_string, sizeof(ramroot_string));
>>+#else
>> if ( initrd_size )
>> memcpy (cmd_line, ramroot_string, sizeof(ramroot_string));
>> else
>> memcpy (cmd_line, netroot_string, sizeof(netroot_string));
>> #endif
>>+#endif
>
> why?
I think this is a fix for a 2.6/INITRAMFS bug.
If you use initramfs
but do not turn on CONFIG_INITRD
and you do not provide a command line
(either in the config file,
or via a boot argument)
then you get the netroot_string command line
Which is NOT what you want for INITRAMFS.
I am sure there is a better way of coding this.
This was just a quick and dirty solution that got cut in
when I turned off a config file command line and suddenly discovered I
was trying to boot off the net.
>
>
>
> <--- snip --->
>
>>diff --git a/arch/ppc/boot/simple/uartlite_tty.c
>>b/arch/ppc/boot/simple/uartlite_tty.c
>
>
> Russell King needs to be CC'd on serial stuff; but looks okay from a
> real-quick look
The uartlite_dbg.c uartlite_tty.c, keyhole_dbg.c, keyhole_dbg.c code
and the CONFIG's controlling them, and the #ifdef's through the boot
code dealing with them are all working fine and have been for atleast
two months. The keyhole_early.c and uartlite_early.c code, once worked,
but when I dicoverd that I could switch pretty much directly from the
reall early stuff to the final serial driver without the _early stuff I
quit work on it, so I probably should discard it.
I can not tell what use xxxx_early is if there is an xxxx_dbg and xxx_tty.
> This stuff all conflicts with my patches of course; but that's to be
> expected. :) Looks okay otherwise
I will try to pull and apply your patches and see if I can rework things.
> this is just a copy of xilinx_ml300 and modified for the e12; I didn't
> look deep into it; but seems okay.
Correct, it seems to be working, that is what I care about.
There are obviously significant similarities. The most fundimental
issue, is that the only certain hardware with the E12 is the PPC405, the
MMU, and the Keyhole (and maybe not that) The PIC, the NIC, almost
everything else may or may not be there.
Pico has just provided me with new firmware that includes a PIC, but
that is for a specific client application where it is required. I have
to have something that can build with or without it.
>>diff --git a/arch/ppc/syslib/keyhole.h b/arch/ppc/syslib/keyhole.h
>>new file mode 100644
>>index 0000000..4b7a374
>>--- /dev/null
>>+++ b/arch/ppc/syslib/keyhole.h
>>@@ -0,0 +1,17 @@
>>+/*
>>+ * arch/ppc/syslib/keyhole.h
>>+ *
>>+ * keyhole prototypes
>>+ *
>>+ * Matt Porter <mporter@kernel.crashing.org>
>
>
> You can add your name to the copyright list.
The majority of my code started with something borrowed. I have done
very little with the headers yet to make sure credit and blame are
appropriately assigned.
I found the references in Documentation, and have to make a pass
through to pic those things up.
>
>>+++ b/arch/ppc/syslib/keyhole_dbg.c
>>@@ -0,0 +1,148 @@
>>+/*
>>+ * arch/ppc/syslib/keyhole_dbg.c
>>+ *
>>+ * Bootloader version of the embedded Xilinx/KEYHOLE driver.
>>+ *
>>+ * Author: David H. Lynch Jr. <dhlii@dlasys.net>
>>+ *
>>+ * 2005 (c) DLA Systems This file is licensed under
>>+ * the terms of the GNU General Public License version 2. This program
>>+ * is licensed "as is" without any warranty of any kind, whether express
>>+ * or implied.
>>+ */
>>+
>>+#include <linux/config.h>
>>+#include <linux/serial_keyhole.h>
>>+#include <linux/serial.h>
>>+#include <linux/tty.h> /* For linux/serial_core.h */
>>+#include <linux/serial_core.h>
>>+#include <linux/serialP.h>
>>+// #include <linux/serial_reg.h>
>>+#include <asm/serial.h>
>>+
>>+
>>+/* SERIAL_PORT_DFNS is defined in <asm/serial.h> */
>>+#ifndef SERIAL_PORT_DFNS
>>+#define SERIAL_PORT_DFNS
>>+#endif
>>+
>>+static struct serial_state rs_table[RS_TABLE_SIZE] = {
>>+ SERIAL_PORT_DFNS /* defined in <asm/serial.h> */
>>+};
>>+static int MillisecTimeout=1000;
>>+void usleep(int t) {
>>+ int ii, waitTime=100;
>>+ while(t) {
>>+ for (ii=0; ii < MillisecTimeout*1000/waitTime; ii++){};
>>+ t--;
>>+ }
>>+}
>
>
> again; what about udelay?
I beleive this is either before there is a kernel, or certainly before
the kernel is initialized.
>>+#if defined(CONFIG_PICO_DEBUG)
>>+#define DEBUG_PRINTK(fmt...) _printk(fmt)
>>+#else
>>+#define DEBUG_PRINTK(fmt...) do { } while (0)
>>+#endif
>>+#define _printk printk
>
>
> The code cleanliness police will probably have something to say about
> you defining your own debug macros. :)
I sort of stole these from elsewhere. Further, they do not appear to
always work - but the style guide suguested macros were preferred to
#ifdef's.
I guess if you do not like this you are really going to appreciate my
private copy of _printk.
It is time for it to go away, but it was really useful having a
different and working output device while debugging the serial driver.
It is unnescacry now.
>>+pico/cross
>>\ No newline at end of file
>
>
> ???
I noticed that too. I have no idea what git diff was talking about.
>>diff --git a/drivers/serial/keyhole.c b/drivers/serial/keyhole.c
>>diff --git a/drivers/serial/keyhole.h b/drivers/serial/keyhole.h
>
>
> I didn't review these; sorry
It does not matter they were close but did not work in the version I
sent to you. They are fixed now.
The E12 uses its unique KEYHOLE fifo (that eventually will support
multiple ttyS's as well as other communications channels to the
Linux/Windows development host.
For the moment the only thing that works is using that fifo as a
pseudo serial device for a console or debugging. But it does work.
The UartLite drivers and the Keyhole drivers are deliberately as nearly
identical as possible. They in turn borrowed heavily from the m32r_sio
driver (for simple answers) and the 8250 driver - because as complex as
it is I assumed it is likely to be the most heavily tested serial driver
in Linux.
>>diff --git a/drivers/serial/printk.c b/drivers/serial/printk.c
>>new file mode 100644
>>index 0000000..5e87489
>>--- /dev/null
>>+++ b/drivers/serial/printk.c
>>@@ -0,0 +1,267 @@
>>+/*
>>+ * arch/ppc/kernel/printf.c
>>+ *
>>+ * early printk code code (almost) all platforms can use
>>+ *
>>+ * Author: David H. Lynch Jr. <dhlii@dlasys.net>
>>+ *
>>+ * Derived heavily from arch/ppc/boot/common/misc-common1.c
>>+ *
>>+ * 20050 (c) DLA Systems This file is licensed under
>>+ * the terms of the GNU General Public License version 2. This program
>>+ * is licensed "as is" without any warranty of any kind, whether express
>>+ * or implied.
>>+ */
>
> You'll need to run this stuff by Tom Rini.
It was solely for debugging. It works well, but it does not need to be
in the kernel.
Speaking of which. At this point the Keyhole and Uartlite drivers
actually work and are at what I would call an early beta/late alpha
stage. I have debugging disabled but not removed. I am not likely to
remove it until they have had a lot more testing.
Probably the most broadly useful part of this massive patch it the
UartLite driver - it should work on any Xilinx FPGA implementing the
UartLite. (including uCLinux on the MicroBlaze) I think it is a perfect
candidate for a separate patch.
I can submit it now - with all the debugging in (but disabled), or
after it has had a month or so of testing at Pico, without debugging.
The same thing is true of the Keyhole - but it is not broadly useful.
The E12 stuff is also just about ready for early beta testing, but Pico
already knows who has their board and wants Linux. So except as it might
be useful to others porting to the Virtex IV, I am not sure that needs
pushed.
>> #ifdef CONFIG_40x
>>diff --git a/include/asm-ppc/ocp_ids.h b/include/asm-ppc/ocp_ids.h
>>index 8ae4b31..5a09b94 100644
>>--- a/include/asm-ppc/ocp_ids.h
>>+++ b/include/asm-ppc/ocp_ids.h
>>@@ -27,6 +27,7 @@
>> #define OCP_VENDOR_IBM 0x1014
>> #define OCP_VENDOR_MOTOROLA OCP_VENDOR_FREESCALE
>> #define OCP_VENDOR_XILINX 0x10ee
>>+#define OCP_VENDOR_PICO 0x10ef // pseudo ID
>> #define OCP_VENDOR_UNKNOWN 0xFFFF
I was hoping for some feedback on OCP_VENDOR_PICO ?
Is there an official place to register/assign these ?
>>
>> /* device identification */
>>diff --git a/include/asm-ppc/reg_booke.h b/include/asm-ppc/reg_booke.h
>>index 00ad9c7..5221970 100644
>>--- a/include/asm-ppc/reg_booke.h
>>+++ b/include/asm-ppc/reg_booke.h
>>@@ -120,6 +120,11 @@ do { \
>> #elif defined(CONFIG_BOOKE)
>> #define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE)
>> #endif
>>+#if defined (CONFIG_PICO_E12)
>>+// The E12 seems to generate spurious Machine Checks - disable them.
>>+#undef MSR_KERNEL
>>+#define MSR_KERNEL (MSR_RI|MSR_IR|MSR_DR|MSR_CE)
>>+#endif
>
>
> Ugh; this worries me.
Most of the work of porting Linux to the E12 took about 1 week.
Tracking this down took three weeks all by itself.
Pico swears that the Machine Check line is not just dangling in space.
But if I turn on Machine Check Exceptions, I never get from Real to
virtual mode. There is an enormous amount of code you tripped over in
head_4xx.S that was primarily to find this problem.
I do not know what to say here. I do not like this either.
The original E12 firmware had the flash at 0x0 and the ram at 0x8000000
or something like that. My personal suspicion is that when they
re-arranged the memory map to org 0 the ram, they did not get something
right and even though everything else is working, it is causing machine
checks- but that is just a guess. I am not part of Pico. I am a
consultant for them. I have a very close relationship and the respect of
the owner, but he is both brilliant and stubborn and if there is an
actual hardware problem it is not going to get fixed until something
else reveals it. In the meantime disabling Machine Checks allowed me to
finish the port.
>
>
>
> Ugh! I'm not doing that again. Make sure your next patch set is broken
> up into bite size emails. That was far too long.
>
> g.
>
Thank You.
^ permalink raw reply
* Re: VFS: Cannot open root device "31:03" or unknown-block(31,3)
From: David Jander @ 2006-01-09 8:45 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: HappyPhot, linuxppc-embedded
In-Reply-To: <20060106150854.918FF353A43@atlas.denx.de>
On Friday 06 January 2006 16:08, Wolfgang Denk wrote:
> This is a serious misunderstanding. There is no such thing like a
> specific kernel version which is supported by the ELDK.
True, but not entirely.
ELDK-3.1.1 has a glibc compiled with support of a certain version of the
kernel (I guess it's 2.4.xx), so newer kernels might run (because they are
obviously backwards compatible), but some features of 2.6 cannot be used
(e.g. support for the latest syscalls, different HZ, etc...)
A second issue is the boot procedure. If you are a beginner with linux, you'd
probably start booting from NFS root as it gets installed in the ELDK/ppc_xxx
directory. That probably won't work very well with latest 2.6 kernels (device
files missing, sysfs not mounted, shmfs has different name, etc...)
A third issue is the compiler issue. Some newer kernels might not compile
correctly anymore with older compilers.
These three things are what I meant with "supported" or "not supported".
> The ELDK is primarily a *toolkit* which works with arbitrary C and
> C++ programs and with any version of the kernel tree (at least in
> theory; very recent version s of the Linux kernel [ > 2.6.14] cannot
> be compiled with ELDK 3.1.x any more, but this is a different issue).
See what I mean? HappyPhot did just that: compile 2.6.14.2 with ELDK 3.1.1!!!
> > > Do you know where to get the infomation about which kernel version it
> > > supports?
>
> The ELDK supports *any* kernel version.
Ok, let's talk about "recommended" kernel then. I would never recommend
someone unexperienced to start with a combination of ELDK-3.1.1 and kernel
2.6.xx.
> > The one that comes with that version of ELDK? Just a guess ;-)
>
> Wrong guess.
But it'd still be the one with most chances of success unless there are known
problems with that kernel on a Sandpoint board.
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* [PATCH 00/10] Xilinx Virtex-* updates
From: grant.likely @ 2006-01-09 8:32 UTC (permalink / raw)
To: glikely, mporter, linuxppc-embedded, gnathita, dhlii
Here's a repost of my Xilinx ML300 and ML403 patches with a few
cleanups, a bit of patch reordering, and rebased to 2.6.15.
Changes:
- Remove xparameters.h as a dependancy to most of the kernel tree
- Rework Virtex-II Pro support to be generic for Virtex-4 also
- Move serial drivers from the OCP bus to the platform bus
- Modify ML300 to use platform bus
- Add support for ML403
- Add ML300 & ML403 defconfigs
I've tested on an ML403
Can someone test on an ML300? (I no longer have one)
Cheers,
g.
^ permalink raw reply
* [PATCH 07/10] Add support for Xilinx ML403 reference design
From: grant.likely @ 2006-01-09 8:33 UTC (permalink / raw)
To: glikely, mporter, linuxppc-embedded, gnathita, dhlii
In-Reply-To: <11367955793438-git-send-email-grant.likely@secretlab.ca>
Signed-off-by: Grant C. Likely <grant.likely@secretlab.ca>
---
arch/ppc/boot/simple/embed_config.c | 43 +++++
arch/ppc/platforms/4xx/Kconfig | 8 +
arch/ppc/platforms/4xx/Makefile | 2
arch/ppc/platforms/4xx/xilinx_ml403.c | 177 ++++++++++++++++++++++
arch/ppc/platforms/4xx/xilinx_ml403.h | 49 ++++++
arch/ppc/platforms/4xx/xparameters/xparameters.h | 13 ++
include/asm-ppc/ibm4xx.h | 4
7 files changed, 293 insertions(+), 3 deletions(-)
create mode 100644 arch/ppc/platforms/4xx/xilinx_ml403.c
create mode 100644 arch/ppc/platforms/4xx/xilinx_ml403.h
d8ec1973726dba317a7212ddbd0299fe459270e0
diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
index df24202..32c7132 100644
--- a/arch/ppc/boot/simple/embed_config.c
+++ b/arch/ppc/boot/simple/embed_config.c
@@ -745,7 +745,7 @@ embed_config(bd_t **bdp)
}
#endif /* WILLOW */
-#ifdef CONFIG_XILINX_ML300
+#if defined(CONFIG_XILINX_ML300)
void
embed_config(bd_t ** bdp)
{
@@ -784,6 +784,47 @@ embed_config(bd_t ** bdp)
}
#endif /* CONFIG_XILINX_ML300 */
+#if defined(CONFIG_XILINX_ML403)
+void
+embed_config(bd_t ** bdp)
+{
+ static const unsigned long line_size = 32;
+ static const unsigned long congruence_classes = 256;
+ unsigned long addr;
+ unsigned long dccr;
+ bd_t *bd;
+
+ /*
+ * Invalidate the data cache if the data cache is turned off.
+ * - The 405 core does not invalidate the data cache on power-up
+ * or reset but does turn off the data cache. We cannot assume
+ * that the cache contents are valid.
+ * - If the data cache is turned on this must have been done by
+ * a bootloader and we assume that the cache contents are
+ * valid.
+ */
+ __asm__("mfdccr %0": "=r" (dccr));
+ if (dccr == 0) {
+ for (addr = 0;
+ addr < (congruence_classes * line_size);
+ addr += line_size) {
+ __asm__("dccci 0,%0": :"b"(addr));
+ }
+ }
+
+ bd = &bdinfo;
+ *bdp = bd;
+ bd->bi_memsize = 64 * 1024 * 1024; /* ML403 has 64 MB of RAM */
+ /* Note, memsize does NOT == XPAR_PLB_DDR_0_MEM0_HIGHADDR+1,
+ * memory controller window is larger than actual mem size */
+ bd->bi_intfreq = XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ;
+ bd->bi_busfreq = XPAR_XUARTNS550_CLOCK_HZ;
+ bd->bi_pci_busfreq = 0;
+ timebase_period_ns = 1000000000 / bd->bi_tbfreq;
+ /* see bi_tbfreq definition in arch/ppc/platforms/4xx/xilinx_ml300.h */
+}
+#endif /* CONFIG_XILINX_ML403 */
+
#ifdef CONFIG_IBM_OPENBIOS
/* This could possibly work for all treeboot roms.
*/
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
index cbb90fc..48def71 100644
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -57,6 +57,10 @@ config XILINX_ML300
help
This option enables support for the Xilinx ML300 evaluation board.
+config XILINX_ML403
+ bool "Xilinx-ML403"
+ help
+ This option enables support for the Xilinx ML403 evaluation board.
endchoice
choice
@@ -205,7 +209,7 @@ config 405GPR
config XILINX_VIRTEX
bool
- depends on XILINX_ML300
+ depends on XILINX_ML300 || XILINX_ML403
default y
config STB03xxx
@@ -215,7 +219,7 @@ config STB03xxx
config EMBEDDEDBOOT
bool
- depends on EP405 || XILINX_ML300
+ depends on EP405 || XILINX_ML300 || XILINX_ML403
default y
config IBM_OPENBIOS
diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
index be4163c..a04a0d0 100644
--- a/arch/ppc/platforms/4xx/Makefile
+++ b/arch/ppc/platforms/4xx/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_REDWOOD_6) += redwood6.o
obj-$(CONFIG_SYCAMORE) += sycamore.o
obj-$(CONFIG_WALNUT) += walnut.o
obj-$(CONFIG_XILINX_ML300) += xilinx_ml300.o
+obj-$(CONFIG_XILINX_ML403) += xilinx_ml403.o
obj-$(CONFIG_405GP) += ibm405gp.o
obj-$(CONFIG_REDWOOD_5) += ibmstb4.o
@@ -27,3 +28,4 @@ obj-$(CONFIG_440SPE) += ppc440spe.o
obj-$(CONFIG_405EP) += ibm405ep.o
obj-$(CONFIG_405GPR) += ibm405gpr.o
obj-$(CONFIG_XILINX_VIRTEX) += virtex.o
+
diff --git a/arch/ppc/platforms/4xx/xilinx_ml403.c b/arch/ppc/platforms/4xx/xilinx_ml403.c
new file mode 100644
index 0000000..4c0c7e4
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xilinx_ml403.c
@@ -0,0 +1,177 @@
+/*
+ * arch/ppc/platforms/4xx/xilinx_ml403.c
+ *
+ * Xilinx ML403 evaluation board initialization
+ *
+ * Author: Grant Likely <grant.likely@secretlab.ca>
+ *
+ * 2005 (c) Secret Lab Technologies Ltd.
+ * 2002-2004 (c) MontaVista Software, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/tty.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/serial_8250.h>
+#include <linux/serialP.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/ppc_sys.h>
+
+#include <syslib/gen550.h>
+#include <platforms/4xx/xparameters/xparameters.h>
+
+/*
+ * As an overview of how the following functions (platform_init,
+ * ml403_map_io, ml403_setup_arch and ml403_init_IRQ) fit into the
+ * kernel startup procedure, here's a call tree:
+ *
+ * start_here arch/ppc/kernel/head_4xx.S
+ * early_init arch/ppc/kernel/setup.c
+ * machine_init arch/ppc/kernel/setup.c
+ * platform_init this file
+ * ppc4xx_init arch/ppc/syslib/ppc4xx_setup.c
+ * parse_bootinfo
+ * find_bootinfo
+ * "setup some default ppc_md pointers"
+ * MMU_init arch/ppc/mm/init.c
+ * *ppc_md.setup_io_mappings == ml403_map_io this file
+ * ppc4xx_map_io arch/ppc/syslib/ppc4xx_setup.c
+ * start_kernel init/main.c
+ * setup_arch arch/ppc/kernel/setup.c
+ * #if defined(CONFIG_KGDB)
+ * *ppc_md.kgdb_map_scc() == gen550_kgdb_map_scc
+ * #endif
+ * *ppc_md.setup_arch == ml403_setup_arch this file
+ * ppc4xx_setup_arch arch/ppc/syslib/ppc4xx_setup.c
+ * ppc4xx_find_bridges arch/ppc/syslib/ppc405_pci.c
+ * init_IRQ arch/ppc/kernel/irq.c
+ * *ppc_md.init_IRQ == ml403_init_IRQ this file
+ * ppc4xx_init_IRQ arch/ppc/syslib/ppc4xx_setup.c
+ * ppc4xx_pic_init arch/ppc/syslib/xilinx_pic.c
+ */
+
+/* Board specifications structures */
+struct ppc_sys_spec *cur_ppc_sys_spec;
+struct ppc_sys_spec ppc_sys_specs[] = {
+ {
+ /* Only one entry, always assume the same design */
+ .ppc_sys_name = "Xilinx ML403 Reference Design",
+ .mask = 0x00000000,
+ .value = 0x00000000,
+ .num_devices = 1,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ VIRTEX_UART,
+ },
+ },
+};
+
+#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
+
+static volatile unsigned *powerdown_base =
+ (volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
+
+static void
+xilinx_power_off(void)
+{
+ local_irq_disable();
+ out_be32(powerdown_base, XPAR_POWER_0_POWERDOWN_VALUE);
+ while (1) ;
+}
+#endif
+
+void __init
+ml403_map_io(void)
+{
+ ppc4xx_map_io();
+
+#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
+ powerdown_base = ioremap((unsigned long) powerdown_base,
+ XPAR_POWER_0_POWERDOWN_HIGHADDR -
+ XPAR_POWER_0_POWERDOWN_BASEADDR + 1);
+#endif
+}
+
+/* Early serial support functions */
+static void __init
+ml403_early_serial_init(int num, struct plat_serial8250_port *pdata)
+{
+#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
+ struct uart_port serial_req;
+
+ memset(&serial_req, 0, sizeof(serial_req));
+ serial_req.mapbase = pdata->mapbase;
+ serial_req.membase = pdata->membase;
+ serial_req.irq = pdata->irq;
+ serial_req.uartclk = pdata->uartclk;
+ serial_req.regshift = pdata->regshift;
+ serial_req.iotype = pdata->iotype;
+ serial_req.flags = pdata->flags;
+ gen550_init(num, &serial_req);
+#endif
+}
+
+void __init
+ml403_early_serial_map(void)
+{
+#ifdef CONFIG_SERIAL_8250
+ struct plat_serial8250_port *pdata;
+ int i = 0;
+
+ pdata = (struct plat_serial8250_port *) ppc_sys_get_pdata(VIRTEX_UART);
+ while(pdata && pdata->flags)
+ {
+ pdata->membase = ioremap(pdata->mapbase, 0x100);
+ ml403_early_serial_init(i, pdata);
+ pdata++;
+ i++;
+ }
+#endif /* CONFIG_SERIAL_8250 */
+}
+
+void __init
+ml403_setup_arch(void)
+{
+ ml403_early_serial_map();
+ ppc4xx_setup_arch(); /* calls ppc4xx_find_bridges() */
+
+ /* Identify the system */
+ printk(KERN_INFO "Xilinx ML403 Reference System (Virtex-4 FX)\n");
+}
+
+/* Called after board_setup_irq from ppc4xx_init_IRQ(). */
+void __init
+ml403_init_irq(void)
+{
+ ppc4xx_init_IRQ();
+}
+
+void __init
+platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ ppc4xx_init(r3, r4, r5, r6, r7);
+
+ identify_ppc_sys_by_id(mfspr(SPRN_PVR));
+
+ ppc_md.setup_arch = ml403_setup_arch;
+ ppc_md.setup_io_mappings = ml403_map_io;
+ ppc_md.init_IRQ = ml403_init_irq;
+
+#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
+ ppc_md.power_off = xilinx_power_off;
+#endif
+
+#ifdef CONFIG_KGDB
+ ppc_md.early_serial_map = ml403_early_serial_map;
+#endif
+}
+
diff --git a/arch/ppc/platforms/4xx/xilinx_ml403.h b/arch/ppc/platforms/4xx/xilinx_ml403.h
new file mode 100644
index 0000000..4735969
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xilinx_ml403.h
@@ -0,0 +1,49 @@
+/*
+ * arch/ppc/platforms/4xx/xilinx_ml403.h
+ *
+ * Include file that defines the Xilinx ML403 reference design
+ *
+ * Author: Grant Likely <grant.likely@secretlab.ca>
+ *
+ * 2005 (c) Secret Lab Technologies Ltd.
+ * 2002-2004 (c) MontaVista Software, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifdef __KERNEL__
+#ifndef __ASM_XILINX_ML403_H__
+#define __ASM_XILINX_ML403_H__
+
+/* ML403 has a Xilinx Virtex-4 FPGA with a PPC405 hard core */
+#include <platforms/4xx/virtex.h>
+
+#ifndef __ASSEMBLY__
+
+#include <linux/types.h>
+
+typedef struct board_info {
+ unsigned int bi_memsize; /* DRAM installed, in bytes */
+ unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
+ unsigned int bi_intfreq; /* Processor speed, in Hz */
+ unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
+ unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
+} bd_t;
+
+/* Some 4xx parts use a different timebase frequency from the internal clock.
+*/
+#define bi_tbfreq bi_intfreq
+
+#endif /* !__ASSEMBLY__ */
+
+/* We don't need anything mapped. Size of zero will accomplish that. */
+#define PPC4xx_ONB_IO_PADDR 0u
+#define PPC4xx_ONB_IO_VADDR 0u
+#define PPC4xx_ONB_IO_SIZE 0u
+
+#define PPC4xx_MACHINE_NAME "Xilinx ML403 Reference Design"
+
+#endif /* __ASM_XILINX_ML403_H__ */
+#endif /* __KERNEL__ */
diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h b/arch/ppc/platforms/4xx/xparameters/xparameters.h
index 26ee822..22b0088 100644
--- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
+++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
@@ -32,6 +32,19 @@
#define VIRTEX_INTC_BASEADDR XPAR_DCR_INTC_0_BASEADDR
#define VIRTEX_INTC_KIND_OF_INTR XPAR_DCR_INTC_0_KIND_OF_INTR
+#elif defined(CONFIG_XILINX_ML403)
+ #include "xparameters_ml403.h"
+
+ /* Serial ports */
+ #define VIRTEX_UART_0_BASEADDR (XPAR_OPB_UART16550_0_BASEADDR + 0x1000)
+ #define VIRTEX_UART_0_IRQ XPAR_OPB_INTC_0_OPB_UART16550_0_IP2INTC_IRPT_INTR
+ #define VIRTEX_UART_0_CLK XPAR_XUARTNS550_CLOCK_HZ
+
+ /* Values for setting up interrupt controller */
+ #define VIRTEX_XINTC_USE_DCR XPAR_XINTC_USE_DCR
+ #define VIRTEX_INTC_BASEADDR XPAR_OPB_INTC_0_BASEADDR
+ #define VIRTEX_INTC_KIND_OF_INTR XPAR_OPB_INTC_0_KIND_OF_INTR
+
#else
/* Add other board xparameter includes here before the #else */
#error No *_xparameters.h file included
diff --git a/include/asm-ppc/ibm4xx.h b/include/asm-ppc/ibm4xx.h
index 6c28ae7..38f9971 100644
--- a/include/asm-ppc/ibm4xx.h
+++ b/include/asm-ppc/ibm4xx.h
@@ -51,6 +51,10 @@
#include <platforms/4xx/xilinx_ml300.h>
#endif
+#if defined(CONFIG_XILINX_ML403)
+#include <platforms/4xx/xilinx_ml403.h>
+#endif
+
#ifndef __ASSEMBLY__
#ifdef CONFIG_40x
--
1.0.6-g58e3
^ permalink raw reply related
* [PATCH 05/10] Add Virtex-4 FX to cpu table
From: grant.likely @ 2006-01-09 8:33 UTC (permalink / raw)
To: glikely, mporter, linuxppc-embedded, gnathita, dhlii
In-Reply-To: <11367955793438-git-send-email-grant.likely@secretlab.ca>
Signed-off-by: Grant C. Likely <grant.likely@secretlab.ca>
---
arch/powerpc/kernel/cputable.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
d088bba0280dacb277ec257287a83fec30b6be28
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 1d85ced..3992c42 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -829,7 +829,7 @@ struct cpu_spec cpu_specs[] = {
.dcache_bsize = 32,
},
{ /* Xilinx Virtex-II Pro */
- .pvr_mask = 0xffff0000,
+ .pvr_mask = 0xfffff000,
.pvr_value = 0x20010000,
.cpu_name = "Virtex-II Pro",
.cpu_features = CPU_FTRS_40X,
@@ -838,6 +838,16 @@ struct cpu_spec cpu_specs[] = {
.icache_bsize = 32,
.dcache_bsize = 32,
},
+ { /* Xilinx Virtex-4 FX */
+ .pvr_mask = 0xfffff000,
+ .pvr_value = 0x20011000,
+ .cpu_name = "Virtex-4 FX",
+ .cpu_features = CPU_FTRS_40X,
+ .cpu_user_features = PPC_FEATURE_32 |
+ PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ },
{ /* 405EP */
.pvr_mask = 0xffff0000,
.pvr_value = 0x51210000,
--
1.0.6-g58e3
^ permalink raw reply related
* [PATCH 04/10] Migrate ML300 reference design to the platform bus
From: grant.likely @ 2006-01-09 8:33 UTC (permalink / raw)
To: glikely, mporter, linuxppc-embedded, gnathita, dhlii
In-Reply-To: <11367955793438-git-send-email-grant.likely@secretlab.ca>
Signed-off-by: Grant C. Likely <grant.likely@secretlab.ca>
---
arch/ppc/Kconfig.debug | 2 -
arch/ppc/platforms/4xx/xilinx_ml300.c | 74 +++++++++++++++++++++++----------
arch/ppc/platforms/4xx/xilinx_ml300.h | 2 -
arch/ppc/syslib/Makefile | 2 -
arch/ppc/syslib/xilinx_pic.c | 10 ++--
5 files changed, 60 insertions(+), 30 deletions(-)
bce11184ffbbcf099d49b6f3764afd842cf891ab
diff --git a/arch/ppc/Kconfig.debug b/arch/ppc/Kconfig.debug
index 61653cb..8cc75ab 100644
--- a/arch/ppc/Kconfig.debug
+++ b/arch/ppc/Kconfig.debug
@@ -67,7 +67,7 @@ config SERIAL_TEXT_DEBUG
config PPC_OCP
bool
- depends on IBM_OCP || XILINX_OCP
+ depends on IBM_OCP
default y
endmenu
diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.c b/arch/ppc/platforms/4xx/xilinx_ml300.c
index b0de0a2..267afb5 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml300.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml300.c
@@ -17,12 +17,14 @@
#include <linux/tty.h>
#include <linux/serial.h>
#include <linux/serial_core.h>
+#include <linux/serial_8250.h>
#include <linux/serialP.h>
#include <asm/io.h>
#include <asm/machdep.h>
-#include <asm/ocp.h>
+#include <asm/ppc_sys.h>
-#include <platforms/4xx/virtex.h> /* for NR_SER_PORTS */
+#include <syslib/gen550.h>
+#include <platforms/4xx/xparameters/xparameters.h>
/*
* As an overview of how the following functions (platform_init,
@@ -54,6 +56,22 @@
* ppc4xx_pic_init arch/ppc/syslib/xilinx_pic.c
*/
+/* Board specifications structures */
+struct ppc_sys_spec *cur_ppc_sys_spec;
+struct ppc_sys_spec ppc_sys_specs[] = {
+ {
+ /* Only one entry, always assume the same design */
+ .ppc_sys_name = "Xilinx ML300 Reference Design",
+ .mask = 0x00000000,
+ .value = 0x00000000,
+ .num_devices = 1,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ VIRTEX_UART,
+ },
+ },
+};
+
#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
static volatile unsigned *powerdown_base =
@@ -80,28 +98,39 @@ ml300_map_io(void)
#endif
}
+/* Early serial support functions */
static void __init
+ml300_early_serial_init(int num, struct plat_serial8250_port *pdata)
+{
+#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
+ struct uart_port serial_req;
+
+ memset(&serial_req, 0, sizeof(serial_req));
+ serial_req.mapbase = pdata->mapbase;
+ serial_req.membase = pdata->membase;
+ serial_req.irq = pdata->irq;
+ serial_req.uartclk = pdata->uartclk;
+ serial_req.regshift = pdata->regshift;
+ serial_req.iotype = pdata->iotype;
+ serial_req.flags = pdata->flags;
+ gen550_init(num, &serial_req);
+#endif
+}
+
+void __init
ml300_early_serial_map(void)
{
#ifdef CONFIG_SERIAL_8250
- struct serial_state old_ports[] = { SERIAL_PORT_DFNS };
- struct uart_port port;
- int i;
-
- /* Setup ioremapped serial port access */
- for (i = 0; i < ARRAY_SIZE(old_ports); i++ ) {
- memset(&port, 0, sizeof(port));
- port.membase = ioremap((phys_addr_t)(old_ports[i].iomem_base), 16);
- port.irq = old_ports[i].irq;
- port.uartclk = old_ports[i].baud_base * 16;
- port.regshift = old_ports[i].iomem_reg_shift;
- port.iotype = SERIAL_IO_MEM;
- port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
- port.line = i;
-
- if (early_serial_setup(&port) != 0) {
- printk("Early serial init of port %d failed\n", i);
- }
+ struct plat_serial8250_port *pdata;
+ int i = 0;
+
+ pdata = (struct plat_serial8250_port *) ppc_sys_get_pdata(VIRTEX_UART);
+ while(pdata && pdata->flags)
+ {
+ pdata->membase = ioremap(pdata->mapbase, 0x100);
+ ml300_early_serial_init(i, pdata);
+ pdata++;
+ i++;
}
#endif /* CONFIG_SERIAL_8250 */
}
@@ -109,9 +138,8 @@ ml300_early_serial_map(void)
void __init
ml300_setup_arch(void)
{
- ppc4xx_setup_arch(); /* calls ppc4xx_find_bridges() */
-
ml300_early_serial_map();
+ ppc4xx_setup_arch(); /* calls ppc4xx_find_bridges() */
/* Identify the system */
printk(KERN_INFO "Xilinx Virtex-II Pro port\n");
@@ -131,6 +159,8 @@ platform_init(unsigned long r3, unsigned
{
ppc4xx_init(r3, r4, r5, r6, r7);
+ identify_ppc_sys_by_id(mfspr(SPRN_PVR));
+
ppc_md.setup_arch = ml300_setup_arch;
ppc_md.setup_io_mappings = ml300_map_io;
ppc_md.init_IRQ = ml300_init_irq;
diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.h b/arch/ppc/platforms/4xx/xilinx_ml300.h
index 8993981..ae8bf13 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml300.h
+++ b/arch/ppc/platforms/4xx/xilinx_ml300.h
@@ -41,7 +41,7 @@ typedef struct board_info {
#define PPC4xx_ONB_IO_VADDR 0u
#define PPC4xx_ONB_IO_SIZE 0u
-#define PPC4xx_MACHINE_NAME "Xilinx ML300"
+#define PPC4xx_MACHINE_NAME "Xilinx ML300 Reference System"
#endif /* __ASM_XILINX_ML300_H__ */
#endif /* __KERNEL__ */
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
index 0c9e79b..10d73ba 100644
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_440SP) += ibm440gx_common.
obj-$(CONFIG_440SPE) += ibm440gx_common.o ibm440sp_common.o ppc440spe_pcie.o
ifeq ($(CONFIG_4xx),y)
ifeq ($(CONFIG_XILINX_VIRTEX),y)
-obj-$(CONFIG_40x) += xilinx_pic.o
+obj-$(CONFIG_40x) += xilinx_pic.o ppc_sys.o
else
ifeq ($(CONFIG_403),y)
obj-$(CONFIG_40x) += ppc403_pic.o
diff --git a/arch/ppc/syslib/xilinx_pic.c b/arch/ppc/syslib/xilinx_pic.c
index 848fb51..206872c 100644
--- a/arch/ppc/syslib/xilinx_pic.c
+++ b/arch/ppc/syslib/xilinx_pic.c
@@ -120,14 +120,14 @@ ppc4xx_pic_init(void)
#error NR_IRQS > 32 not supported
#endif
-#if XPAR_XINTC_USE_DCR == 0
- intc = ioremap(XPAR_INTC_0_BASEADDR, 32);
+#if VIRTEX_XINTC_USE_DCR == 0
+ intc = ioremap(VIRTEX_INTC_BASEADDR, 32);
printk(KERN_INFO "Xilinx INTC #0 at 0x%08lX mapped to 0x%08lX\n",
- (unsigned long) XPAR_INTC_0_BASEADDR, (unsigned long) intc);
+ (unsigned long) VIRTEX_INTC_BASEADDR, (unsigned long) intc);
#else
printk(KERN_INFO "Xilinx INTC #0 at 0x%08lX (DCR)\n",
- (unsigned long) XPAR_INTC_0_BASEADDR);
+ (unsigned long) VIRTEX_INTC_BASEADDR);
#endif
/*
@@ -147,7 +147,7 @@ ppc4xx_pic_init(void)
for (i = 0; i < NR_IRQS; ++i) {
irq_desc[i].handler = &xilinx_intc;
- if (XPAR_INTC_0_KIND_OF_INTR & (0x00000001 << i))
+ if (VIRTEX_INTC_KIND_OF_INTR & (0x00000001 << i))
irq_desc[i].status &= ~IRQ_LEVEL;
else
irq_desc[i].status |= IRQ_LEVEL;
--
1.0.6-g58e3
^ permalink raw reply related
* [PATCH 02/10] Make Virtex-II Pro support generic for all Virtex devices
From: grant.likely @ 2006-01-09 8:32 UTC (permalink / raw)
To: glikely, mporter, linuxppc-embedded, gnathita, dhlii
In-Reply-To: <11367955793438-git-send-email-grant.likely@secretlab.ca>
The PPC405 hard core is used in both the Virtex-II Pro and Virtex 4 FX
FPGAs. This patch cleans up the Virtex naming convention to reflect more
than just the Virtex-II Pro.
Rename files virtex-ii_pro.[ch] to virtex.[ch]
Rename config value VIRTEX_II_PRO to XILINX_VIRTEX
Signed-off-by: Grant C. Likely <grant.likely@secretlab.ca>
---
arch/ppc/platforms/4xx/Kconfig | 2 -
arch/ppc/platforms/4xx/Makefile | 2 -
arch/ppc/platforms/4xx/virtex-ii_pro.c | 60 -------------------
arch/ppc/platforms/4xx/virtex-ii_pro.h | 99 --------------------------------
arch/ppc/platforms/4xx/virtex.c | 60 +++++++++++++++++++
arch/ppc/platforms/4xx/virtex.h | 99 ++++++++++++++++++++++++++++++++
arch/ppc/platforms/4xx/xilinx_ml300.c | 2 -
arch/ppc/platforms/4xx/xilinx_ml300.h | 2 -
arch/ppc/syslib/Makefile | 2 -
9 files changed, 164 insertions(+), 164 deletions(-)
delete mode 100644 arch/ppc/platforms/4xx/virtex-ii_pro.c
delete mode 100644 arch/ppc/platforms/4xx/virtex-ii_pro.h
create mode 100644 arch/ppc/platforms/4xx/virtex.c
create mode 100644 arch/ppc/platforms/4xx/virtex.h
35c3b44dc49519e5e47e8d7e52da2b8f31652043
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
index d883791..73d9bef 100644
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -208,7 +208,7 @@ config 405GPR
depends on SYCAMORE
default y
-config VIRTEX_II_PRO
+config XILINX_VIRTEX
bool
depends on XILINX_ML300
default y
diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
index c9bb611..be4163c 100644
--- a/arch/ppc/platforms/4xx/Makefile
+++ b/arch/ppc/platforms/4xx/Makefile
@@ -26,4 +26,4 @@ obj-$(CONFIG_440SP) += ibm440sp.o
obj-$(CONFIG_440SPE) += ppc440spe.o
obj-$(CONFIG_405EP) += ibm405ep.o
obj-$(CONFIG_405GPR) += ibm405gpr.o
-obj-$(CONFIG_VIRTEX_II_PRO) += virtex-ii_pro.o
+obj-$(CONFIG_XILINX_VIRTEX) += virtex.o
diff --git a/arch/ppc/platforms/4xx/virtex-ii_pro.c b/arch/ppc/platforms/4xx/virtex-ii_pro.c
deleted file mode 100644
index 097cc9d..0000000
--- a/arch/ppc/platforms/4xx/virtex-ii_pro.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * arch/ppc/platforms/4xx/virtex-ii_pro.c
- *
- * Author: MontaVista Software, Inc.
- * source@mvista.com
- *
- * 2002-2004 (c) MontaVista Software, Inc. This file is licensed under the
- * terms of the GNU General Public License version 2. This program is licensed
- * "as is" without any warranty of any kind, whether express or implied.
- */
-
-#include <linux/config.h>
-#include <linux/init.h>
-#include <asm/ocp.h>
-#include "virtex-ii_pro.h"
-
-/* 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 = OCP_VENDOR_XILINX,
- .function = OCP_FUNC_16550,
- .index = 1,
- .paddr = XPAR_UARTNS550_1_BASEADDR,
- .irq = XPAR_INTC_0_UARTNS550_1_VEC_ID,
- .pm = OCP_CPM_NA
- },
-#ifdef XPAR_UARTNS550_2_BASEADDR
- { .vendor = OCP_VENDOR_XILINX,
- .function = OCP_FUNC_16550,
- .index = 2,
- .paddr = XPAR_UARTNS550_2_BASEADDR,
- .irq = XPAR_INTC_0_UARTNS550_2_VEC_ID,
- .pm = OCP_CPM_NA
- },
-#ifdef XPAR_UARTNS550_3_BASEADDR
- { .vendor = OCP_VENDOR_XILINX,
- .function = OCP_FUNC_16550,
- .index = 3,
- .paddr = XPAR_UARTNS550_3_BASEADDR,
- .irq = XPAR_INTC_0_UARTNS550_3_VEC_ID,
- .pm = OCP_CPM_NA
- },
-#ifdef XPAR_UARTNS550_4_BASEADDR
-#error Edit this file to add more devices.
-#endif /* 4 */
-#endif /* 3 */
-#endif /* 2 */
-#endif /* 1 */
-#endif /* 0 */
- { .vendor = OCP_VENDOR_INVALID
- }
-};
diff --git a/arch/ppc/platforms/4xx/virtex-ii_pro.h b/arch/ppc/platforms/4xx/virtex-ii_pro.h
deleted file mode 100644
index 026130c..0000000
--- a/arch/ppc/platforms/4xx/virtex-ii_pro.h
+++ /dev/null
@@ -1,99 +0,0 @@
-/*
- * arch/ppc/platforms/4xx/virtex-ii_pro.h
- *
- * Include file that defines the Xilinx Virtex-II Pro processor
- *
- * Author: MontaVista Software, Inc.
- * source@mvista.com
- *
- * 2002-2004 (c) MontaVista Software, Inc. This file is licensed under the
- * terms of the GNU General Public License version 2. This program is licensed
- * "as is" without any warranty of any kind, whether express or implied.
- */
-
-#ifdef __KERNEL__
-#ifndef __ASM_VIRTEXIIPRO_H__
-#define __ASM_VIRTEXIIPRO_H__
-
-#include <linux/config.h>
-#include <platforms/4xx/xparameters/xparameters.h>
-
-/* serial defines */
-
-#define RS_TABLE_SIZE 4 /* change this and add more devices below
- if you have more then 4 16x50 UARTs */
-
-#define BASE_BAUD (XPAR_UARTNS550_0_CLOCK_FREQ_HZ/16)
-
-/* The serial ports in the Virtex-II Pro have each I/O byte in the
- * LSByte of a word. This means that iomem_reg_shift needs to be 2 to
- * change the byte offsets into word offsets. In addition the base
- * addresses need to have 3 added to them to get to the LSByte.
- */
-#define STD_UART_OP(num) \
- { 0, BASE_BAUD, 0, XPAR_INTC_0_UARTNS550_##num##_VEC_ID, \
- ASYNC_BOOT_AUTOCONF, \
- .iomem_base = (u8 *)XPAR_UARTNS550_##num##_BASEADDR + 3, \
- .iomem_reg_shift = 2, \
- .io_type = SERIAL_IO_MEM},
-
-#if defined(XPAR_INTC_0_UARTNS550_0_VEC_ID)
-#define ML300_UART0 STD_UART_OP(0)
-#else
-#define ML300_UART0
-#endif
-
-#if defined(XPAR_INTC_0_UARTNS550_1_VEC_ID)
-#define ML300_UART1 STD_UART_OP(1)
-#else
-#define ML300_UART1
-#endif
-
-#if defined(XPAR_INTC_0_UARTNS550_2_VEC_ID)
-#define ML300_UART2 STD_UART_OP(2)
-#else
-#define ML300_UART2
-#endif
-
-#if defined(XPAR_INTC_0_UARTNS550_3_VEC_ID)
-#define ML300_UART3 STD_UART_OP(3)
-#else
-#define ML300_UART3
-#endif
-
-#if defined(XPAR_INTC_0_UARTNS550_4_VEC_ID)
-#error Edit this file to add more devices.
-#elif defined(XPAR_INTC_0_UARTNS550_3_VEC_ID)
-#define NR_SER_PORTS 4
-#elif defined(XPAR_INTC_0_UARTNS550_2_VEC_ID)
-#define NR_SER_PORTS 3
-#elif defined(XPAR_INTC_0_UARTNS550_1_VEC_ID)
-#define NR_SER_PORTS 2
-#elif defined(XPAR_INTC_0_UARTNS550_0_VEC_ID)
-#define NR_SER_PORTS 1
-#else
-#define NR_SER_PORTS 0
-#endif
-
-#if defined(CONFIG_UART0_TTYS0)
-#define SERIAL_PORT_DFNS \
- ML300_UART0 \
- ML300_UART1 \
- ML300_UART2 \
- ML300_UART3
-#endif
-
-#if defined(CONFIG_UART0_TTYS1)
-#define SERIAL_PORT_DFNS \
- ML300_UART1 \
- ML300_UART0 \
- ML300_UART2 \
- ML300_UART3
-#endif
-
-#define DCRN_CPMFR_BASE 0
-
-#include <asm/ibm405.h>
-
-#endif /* __ASM_VIRTEXIIPRO_H__ */
-#endif /* __KERNEL__ */
diff --git a/arch/ppc/platforms/4xx/virtex.c b/arch/ppc/platforms/4xx/virtex.c
new file mode 100644
index 0000000..1de7a27
--- /dev/null
+++ b/arch/ppc/platforms/4xx/virtex.c
@@ -0,0 +1,60 @@
+/*
+ * arch/ppc/platforms/4xx/virtex.c
+ *
+ * Author: MontaVista Software, Inc.
+ * source@mvista.com
+ *
+ * 2002-2004 (c) MontaVista Software, Inc. This file is licensed under the
+ * terms of the GNU General Public License version 2. This program is licensed
+ * "as is" without any warranty of any kind, whether express or implied.
+ */
+
+#include <linux/config.h>
+#include <linux/init.h>
+#include <asm/ocp.h>
+#include <platform/4xx/virtex.h>
+
+/* 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 = OCP_VENDOR_XILINX,
+ .function = OCP_FUNC_16550,
+ .index = 1,
+ .paddr = XPAR_UARTNS550_1_BASEADDR,
+ .irq = XPAR_INTC_0_UARTNS550_1_VEC_ID,
+ .pm = OCP_CPM_NA
+ },
+#ifdef XPAR_UARTNS550_2_BASEADDR
+ { .vendor = OCP_VENDOR_XILINX,
+ .function = OCP_FUNC_16550,
+ .index = 2,
+ .paddr = XPAR_UARTNS550_2_BASEADDR,
+ .irq = XPAR_INTC_0_UARTNS550_2_VEC_ID,
+ .pm = OCP_CPM_NA
+ },
+#ifdef XPAR_UARTNS550_3_BASEADDR
+ { .vendor = OCP_VENDOR_XILINX,
+ .function = OCP_FUNC_16550,
+ .index = 3,
+ .paddr = XPAR_UARTNS550_3_BASEADDR,
+ .irq = XPAR_INTC_0_UARTNS550_3_VEC_ID,
+ .pm = OCP_CPM_NA
+ },
+#ifdef XPAR_UARTNS550_4_BASEADDR
+#error Edit this file to add more devices.
+#endif /* 4 */
+#endif /* 3 */
+#endif /* 2 */
+#endif /* 1 */
+#endif /* 0 */
+ { .vendor = OCP_VENDOR_INVALID
+ }
+};
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
new file mode 100644
index 0000000..049c767
--- /dev/null
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -0,0 +1,99 @@
+/*
+ * arch/ppc/platforms/4xx/virtex.h
+ *
+ * Include file that defines the Xilinx Virtex-II Pro processor
+ *
+ * Author: MontaVista Software, Inc.
+ * source@mvista.com
+ *
+ * 2002-2004 (c) MontaVista Software, Inc. This file is licensed under the
+ * terms of the GNU General Public License version 2. This program is licensed
+ * "as is" without any warranty of any kind, whether express or implied.
+ */
+
+#ifdef __KERNEL__
+#ifndef __ASM_VIRTEX_H__
+#define __ASM_VIRTEX_H__
+
+#include <linux/config.h>
+#include <platforms/4xx/xparameters/xparameters.h>
+
+/* serial defines */
+
+#define RS_TABLE_SIZE 4 /* change this and add more devices below
+ if you have more then 4 16x50 UARTs */
+
+#define BASE_BAUD (XPAR_UARTNS550_0_CLOCK_FREQ_HZ/16)
+
+/* The serial ports in the Virtex-II Pro have each I/O byte in the
+ * LSByte of a word. This means that iomem_reg_shift needs to be 2 to
+ * change the byte offsets into word offsets. In addition the base
+ * addresses need to have 3 added to them to get to the LSByte.
+ */
+#define STD_UART_OP(num) \
+ { 0, BASE_BAUD, 0, XPAR_INTC_0_UARTNS550_##num##_VEC_ID, \
+ ASYNC_BOOT_AUTOCONF, \
+ .iomem_base = (u8 *)XPAR_UARTNS550_##num##_BASEADDR + 3, \
+ .iomem_reg_shift = 2, \
+ .io_type = SERIAL_IO_MEM},
+
+#if defined(XPAR_INTC_0_UARTNS550_0_VEC_ID)
+#define ML300_UART0 STD_UART_OP(0)
+#else
+#define ML300_UART0
+#endif
+
+#if defined(XPAR_INTC_0_UARTNS550_1_VEC_ID)
+#define ML300_UART1 STD_UART_OP(1)
+#else
+#define ML300_UART1
+#endif
+
+#if defined(XPAR_INTC_0_UARTNS550_2_VEC_ID)
+#define ML300_UART2 STD_UART_OP(2)
+#else
+#define ML300_UART2
+#endif
+
+#if defined(XPAR_INTC_0_UARTNS550_3_VEC_ID)
+#define ML300_UART3 STD_UART_OP(3)
+#else
+#define ML300_UART3
+#endif
+
+#if defined(XPAR_INTC_0_UARTNS550_4_VEC_ID)
+#error Edit this file to add more devices.
+#elif defined(XPAR_INTC_0_UARTNS550_3_VEC_ID)
+#define NR_SER_PORTS 4
+#elif defined(XPAR_INTC_0_UARTNS550_2_VEC_ID)
+#define NR_SER_PORTS 3
+#elif defined(XPAR_INTC_0_UARTNS550_1_VEC_ID)
+#define NR_SER_PORTS 2
+#elif defined(XPAR_INTC_0_UARTNS550_0_VEC_ID)
+#define NR_SER_PORTS 1
+#else
+#define NR_SER_PORTS 0
+#endif
+
+#if defined(CONFIG_UART0_TTYS0)
+#define SERIAL_PORT_DFNS \
+ ML300_UART0 \
+ ML300_UART1 \
+ ML300_UART2 \
+ ML300_UART3
+#endif
+
+#if defined(CONFIG_UART0_TTYS1)
+#define SERIAL_PORT_DFNS \
+ ML300_UART1 \
+ ML300_UART0 \
+ ML300_UART2 \
+ ML300_UART3
+#endif
+
+#define DCRN_CPMFR_BASE 0
+
+#include <asm/ibm405.h>
+
+#endif /* __ASM_VIRTEX_H__ */
+#endif /* __KERNEL__ */
diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.c b/arch/ppc/platforms/4xx/xilinx_ml300.c
index 0b1b77d..b0de0a2 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml300.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml300.c
@@ -22,7 +22,7 @@
#include <asm/machdep.h>
#include <asm/ocp.h>
-#include <platforms/4xx/virtex-ii_pro.h> /* for NR_SER_PORTS */
+#include <platforms/4xx/virtex.h> /* for NR_SER_PORTS */
/*
* As an overview of how the following functions (platform_init,
diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.h b/arch/ppc/platforms/4xx/xilinx_ml300.h
index f8c5884..8993981 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml300.h
+++ b/arch/ppc/platforms/4xx/xilinx_ml300.h
@@ -16,7 +16,7 @@
#define __ASM_XILINX_ML300_H__
/* ML300 has a Xilinx Virtex-II Pro processor */
-#include <platforms/4xx/virtex-ii_pro.h>
+#include <platforms/4xx/virtex.h>
#ifndef __ASSEMBLY__
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
index 5b7f2b8..0c9e79b 100644
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_440GX) += ibm440gx_common.
obj-$(CONFIG_440SP) += ibm440gx_common.o ibm440sp_common.o
obj-$(CONFIG_440SPE) += ibm440gx_common.o ibm440sp_common.o ppc440spe_pcie.o
ifeq ($(CONFIG_4xx),y)
-ifeq ($(CONFIG_VIRTEX_II_PRO),y)
+ifeq ($(CONFIG_XILINX_VIRTEX),y)
obj-$(CONFIG_40x) += xilinx_pic.o
else
ifeq ($(CONFIG_403),y)
--
1.0.6-g58e3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox