Xilinx ML300 board support (very basic)
PATCH 1/1 Xilinx ML300 board support (very basic)
Adds minimal Xilinx ML300 board support (enough to boot with ramdisk). The only peripheral devices supported are 16x50 compatible UARTs.
arch/ppc/boot/simple/embed_config.c +18 -15
@@ -749,25 +749,25 @@static const unsigned long line_size =32 ;static const unsigned long congruence_classes =256 ;unsigned long addr; -u_char *cp; -int i; +unsigned long dccr;bd_t *bd;/* -* At one point, we were getting machine checks. Linux was not -* invalidating the data cache before it was enabled. The -* following code was added to do that. Soon after we had done -* that, we found the real reasons for the machine checks. I've -* run the kernel a few times with the following code -* temporarily removed without any apparent problems. However, -* I objdump'ed the kernel and boot code and found out that -* there were no other dccci's anywhere, so I put the code back -* in and have been reluctant to remove it. It seems safer to -* just leave it here. +* 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. */ -for (addr =0 ; - addr < (congruence_classes * line_size); addr += line_size) { - __asm__("dccci 0,%0" : :"b" (addr)); + __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;
@@ -775,6 +775,9 @@ bd->bi_memsize =XPAR_DDR_0_SIZE ; bd->bi_intfreq =XPAR_CORE_CLOCK_FREQ_HZ ; bd->bi_busfreq =XPAR_PLB_CLOCK_FREQ_HZ ; + bd->bi_pci_busfreq =XPAR_PCI_0_CLOCK_FREQ_HZ ; + timebase_period_ns =1000000000 / bd->bi_tbfreq; + /* see bi_tbfreq definition in arch/ppc/platforms/4xx/xilinx_ml300.h */ }#endif /* CONFIG_XILINX_ML300 */
arch/ppc/Kconfig.debug +1 -1
@@ -78,7 +78,7 @@ config PPC_OCP bool - depends on IBM_OCP || FSL_OCP + depends on IBM_OCP || FSL_OCP || XILINX_OCP default y endmenu
arch/ppc/platforms/4xx/Kconfig +16 -1
@@ -56,6 +56,11 @@ help This option enables support for the IBM PPC405GP evaluation board. +config XILINX_ML300 + bool "Xilinx-ML300" + help + This option enables support for the Xilinx ML300 evaluation board. + endchoice choice
@@ -130,6 +135,11 @@ depends on ASH || BUBINGA || CPCI405 || EBONY || EP405 || OCOTEA || REDWOOD_5 || REDWOOD_6 || SYCAMORE || WALNUT default y +config XILINX_OCP + bool + depends on XILINX_ML300 + default y + config IBM_EMAC4 bool depends on 440GX
@@ -160,6 +170,11 @@ depends on SYCAMORE default y +config VIRTEX_II_PRO + bool + depends on XILINX_ML300 + default y + config STB03xxx bool depends on REDWOOD_5 || REDWOOD_6
@@ -167,7 +182,7 @@ config EMBEDDEDBOOT bool - depends on EP405 + depends on EP405 || XILINX_ML300 default y config IBM_OPENBIOS
arch/ppc/platforms/4xx/Makefile +2 -0
@@ -12,6 +12,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_405GP) += ibm405gp.o obj-$(CONFIG_REDWOOD_5) += ibmstb4.o
@@ -21,3 +22,4 @@ obj-$(CONFIG_440GX) += ibm440gx.o obj-$(CONFIG_405EP) += ibm405ep.o obj-$(CONFIG_405GPR) += ibm405gpr.o +obj-$(CONFIG_VIRTEX_II_PRO) += virtex-ii_pro.o
arch/ppc/platforms/4xx/virtex-ii_pro.c +60 -0
60 lines not on this page · raw message
arch/ppc/platforms/4xx/virtex-ii_pro.h +99 -0
99 lines not on this page · raw message
arch/ppc/platforms/4xx/xilinx_ml300.c +164 -0
164 lines not on this page · raw message
arch/ppc/platforms/4xx/xilinx_ml300.h +47 -0
47 lines not on this page · raw message
arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h +310 -0
310 lines not on this page · raw message
arch/ppc/syslib/Makefile +6 -1
@@ -14,7 +14,12 @@ obj-$(CONFIG_440GP) += ibm440gp_common.o obj-$(CONFIG_440GX) += ibm440gx_common.o ifeq ($(CONFIG_4xx),y) -obj-$(CONFIG_4xx) += ppc4xx_pic.o +ifeq ($(CONFIG_VIRTEX_II_PRO),y) +obj-$(CONFIG_40x) += xilinx_pic.o +else +obj-$(CONFIG_40x) += ppc4xx_pic.o +endif +obj-$(CONFIG_44x) += ppc4xx_pic.o obj-$(CONFIG_40x) += ppc4xx_setup.o obj-$(CONFIG_GEN_RTC) += todc_time.o obj-$(CONFIG_PPC4xx_DMA) += ppc4xx_dma.o
arch/ppc/syslib/xilinx_pic.c +142 -0
142 lines not on this page · raw message
include/asm-ppc/ibm4xx.h +4 -0
@@ -59,6 +59,10 @@#include <platforms/4xx/walnut.h> #endif +#if defined(CONFIG_XILINX_ML300 ) +#include <platforms/4xx/xilinx_ml300.h> +#endif +#ifndef __ASSEMBLY__#ifdef CONFIG_40x
include/asm-ppc/xparameters.h +18 -0
@@ -0,0 +1,18 @@ +/* +* include/asm-ppc/xparameters.h +* +* This file includes the correct xparameters.h for the CONFIG'ed board +* +* Author: MontaVista Software, Inc. +* [email protected] +* +* 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> + +#if defined(CONFIG_XILINX_ML300 ) +#include <platforms/4xx/xparameters/xparameters_ml300.h> +#endif
Quoted 4 lines · Andrei Konovalov
Adds minimal Xilinx ML300 board support (enough to boot with ramdisk). The only peripheral devices supported are 16x50 compatible UARTs.
Signed-off-by Andrei Konovalov <[email protected]>
I'll test this if I get chance soon.
Quoted 9 lines
/*arch/ppc/boot/simple/embed_config.c +0
-8-* At one point, we were getting machine checks. Linux was not -* invalidating the data cache before it was enabled. The -* following code was added to do that. Soon after we had done -* that, we found the real reasons for the machine checks. I've -* run the kernel a few times with the following code -* temporarily removed without any apparent problems. However, -* I objdump'ed the kernel and boot code and found out that -* there were no other dccci's anywhere, so I put the code back
arch/ppc/boot/simple/embed_config.c line 763
Quoted 10 lines
arch/ppc/boot/simple/embed_config.c +7
-2-* in and have been reluctant to remove it. It seems safer to -* just leave it here. +* 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. */
Er...the caveat about the MSR is still worth noting - I had this problem and for a while couldn't figure out why the fsck the board wouldn't come up with cacheing enabled (I've written patches for debugging that turn off various cacheing by modifying the pte macros, etc.) and *still* believe we're not clean from unwanted machine checks here. Just FYI.
arch/ppc/platforms/4xx/xilinx_ml300.h line 42
Quoted 4 lines
arch/ppc/platforms/4xx/xilinx_ml300.h +4
-0+/* 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
:-)
arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h line 9
Quoted 4 lines
arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h +4
-0+* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License as published by the +* Free Software Foundation; either version 2 of the License, or (at your +* option) any later version.
...and then:
arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h line 27
Quoted 3 lines
arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h +3
-0+* Xilinx hardware products are not intended for use in life support +* appliances, devices, or systems. Use in such applications is +* expressly prohibited.
I've always loved it how Xilinx GPL disclaimers cunningly aren't. They might want to wake up and smell the coffee at some point.
Andrei, you'll want to modify the ML300 xparameters stuff to allow it's location to be specified by a parameter. People who want to use (ewww, spit) autogenerated Xilinx xparameters.h from their EDK will probably also want to choose where it lives.
Quoted 3 lines
+ *
arch/ppc/syslib/xilinx_pic.c
+ *
+ * Interrupt controller driver for Xilinx Virtex-II Pro.
Nice. Better than the original and now handles different types of interrupts.
Jon.
Quoted 4 lines · Jon Masters
On Fri, 08 Oct 2004 21:23:01 +0400, Andrei Konovalov <[email protected]> wrote:
Quoted 8 lines
Quoted 4 lines
Adds minimal Xilinx ML300 board support (enough to boot with ramdisk). The only peripheral devices supported are 16x50 compatible UARTs.
Signed-off-by Andrei Konovalov <[email protected]>I'll test this if I get chance soon.
Great!
Quoted 22 lines
Quoted 10 lines
/*arch/ppc/boot/simple/embed_config.c +0
-8-* At one point, we were getting machine checks. Linux was not -* invalidating the data cache before it was enabled. The -* following code was added to do that. Soon after we had done -* that, we found the real reasons for the machine checks. I've -* run the kernel a few times with the following code -* temporarily removed without any apparent problems. However, -* I objdump'ed the kernel and boot code and found out that -* there were no other dccci's anywhere, so I put the code back arch/ppc/boot/simple/embed_config.c line 763
Quoted 10 lines
arch/ppc/boot/simple/embed_config.c +7
-2-* in and have been reluctant to remove it. It seems safer to -* just leave it here. +* 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. */
Quoted 7 lines
Er...the caveat about the MSR is still worth noting - I had this problem and for a while couldn't figure out why the fsck the board wouldn't come up with cacheing enabled (I've written patches for debugging that turn off various cacheing by modifying the pte macros, etc.) and *still* believe we're not clean from unwanted machine checks here. Just FYI.
The code which follows the comment above works for me with both ML300 and the Memec 2VP7 boards I have.
Do you mean that some boards (or FPGA designs) need cacheing to be disabled completely?
If this is the case, and you have the patch that handles this, I would welcome that patch to follow mine.
Is there any chance for me to reproduce that problem on my site with the hardware I have (1. ML300; 2. Memec 2VP7 board plus the COMM and the System ACE modules)?
Quoted 1 line
...
Quoted 10 lines
arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h line 9
Quoted 5 lines
arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h +4
-0+* This program is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License as published by the +* Free Software Foundation; either version 2 of the License, or (at your +* option) any later version. ...and then:
Quoted 7 lines
arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h line 27
Quoted 3 lines
arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h +3
-0+* Xilinx hardware products are not intended for use in life support +* appliances, devices, or systems. Use in such applications is +* expressly prohibited. I've always loved it how Xilinx GPL disclaimers cunningly aren't. They might want to wake up and smell the coffee at some point.
I know this doesn't look good.
If it *does* prevent this code from getting into the kernel tree I could try contacting Xilinx (doubt it will help though - they have already changed the copyrights once to be more community friendly).
Quoted 6 lines
Andrei, you'll want to modify the ML300 xparameters stuff to allow it's location to be specified by a parameter. People who want to use (ewww, spit) autogenerated Xilinx
xparameters.hfrom their EDK will probably also want to choose where it lives.
Why renaming someone's autogenerated xparameters.h into xparameters_my_ml300.h and placing it into arch/ppc/platforms/4xx/xparameters/,
defining CONFIG_XILINX_MY_ML300, and adding
few lines to include/asm-ppc/xparameters.h like:
#if defined(CONFIG_XILINX_ML300)
#include <platforms/4xx/xparameters/xparameters_ml300.h> #endif
+#if defined(CONFIG_XILINX_MY_ML300)
+#include <platforms/4xx/xparameters/xparameters_my_ml300.h> +#endif
doesn't work in your oppinion?
Quoted 1 line
...
Quoted 4 lines
Jon.
Thanks,
Andrei
Quoted 2 lines · Andrei Konovalov
Do you mean that some boards (or FPGA designs) need cacheing to be disabled completely?
No. I mean that I believe you may still get unwanted Machine Checks even if you setup cacheing correctly. I'll check this out now that I've got a reasonably stable platform which is working - when I last looked at the Machine Check issue there might have been other root causes.
For debugging purposes, I did at one point have to completely disable cacheing in order to make it easier to see whether the memory controller or RAM was faulty when we started seeing memory weirdness. This turned out to be another side effect of not correctly initialising the cacheing before turning it on. That'll teach me to remove magic lines of code from my firmware that were seemingly doing nothing useful :-).
Quoted 2 lines
If this is the case, and you have the patch that handles this, I would welcome that patch to follow mine.
I'll dig out the relevent bits.
Quoted 3 lines
Is there any chance for me to reproduce that problem on my site with the hardware I have (1. ML300; 2. Memec 2VP7 board plus the COMM and the System ACE modules)?
So you don't see any unwanted Machine Checks on your board now? That's interesting. I'll certainly look in to that some more - it could well be a design difference as you probably have some reference design you're using, whereas we have various inhouse custom builds for our hw.
jcm>> I've always loved it how Xilinx GPL disclaimers cunningly aren't.
Quoted 1 line
I know this doesn't look good.
They'll have to change it before people are happy. Whether it gets in to the stock kernel is a matter of principle on the part of those signing off on the patches. But I think you can get around this by not including the parameters file if absolutely necessary.
Quoted 3 lines
If it *does* prevent this code from getting into the kernel tree I could try contacting Xilinx (doubt it will help though - they have already changed the copyrights once to be more community friendly).
I think it's likely a typical corporate legalism with whoever came up with that mutually self-inconsistent disclaimer that they bolt on to stuff - "GP-what? Free? The sky is falling?". You can try talking to them about it though.
Quoted 19 lines
Quoted 5 lines
Andrei, you'll want to modify the ML300 xparameters stuff to allow it's location to be specified by a parameter. People who want to use (ewww, spit) autogenerated Xilinx
xparameters.hfrom their EDK will probably also want to choose where it lives.Why renaming someone's autogenerated
xparameters.hintoxparameters_my_ml300.hand placing it intoarch/ppc/platforms/4xx/xparameters/,
definingCONFIG_XILINX_MY_ML300, and adding
few lines toinclude/asm-ppc/xparameters.hlike:#if
defined(CONFIG_XILINX_ML300)
#include <platforms/4xx/xparameters/xparameters_ml300.h> #endif(quoted diff) +3
-0+#if defined(CONFIG_XILINX_MY_ML300) +#include <platforms/4xx/xparameters/xparameters_my_ml300.h> +#endif
Quoted 1 line
doesn't work in your oppinion?
I was just thinking about how this can make life easier for Monta's GUI builder stuff, and similar scripted builds of the kernel tree.
Jon.
On Sat, Oct 09, 2004 at 08:40:31PM +0100, Jon Masters wrote:
[snip]
Quoted 4 lines
Andrei, you'll want to modify the ML300 xparameters stuff to allow it's location to be specified by a parameter. People who want to use (ewww, spit) autogenerated Xilinx
xparameters.hfrom their EDK will probably also want to choose where it lives.
Putting this on its ear slightly, how goes moving over the ppc64 device tree stuff?
Signature · 2 lines
Tom Rini http://gate.crashing.org/~trini/
Quoted 2 lines · Tom Rini
Putting this on its ear slightly, how goes moving over the ppc64 device tree stuff?
Replied via another thread. I spent some time at the tail end of last week on this and then got side tracked getting mol to work (for testing rather than rebooting the box I'm developing on) on Sunday so have nothing to post yet - but I should do soon. I'll update you this week.
Jon.