Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
On Mon, Jun 23, 2008 at 09:35:56PM -0400, Josh Boyer wrote: On Mon, 23 Jun 2008 15:30:35 -0600 John Linn [EMAIL PROTECTED] wrote: I'll try to better understand if we can detect the compressed device tree and if we really have to disable the APU. What's the reasoning for being independent of the kernel, maybe it's obvious to everyone but me? The intention, as I understand it, is that the wrapper utilities can be installed stand-alone and used to wrap other kernels if needs be. In practice I've not seen this happen yet, as most PowerPC kernels are built directly from the kernel source. Fedora does have a separate package for the wrapper bits, but I'm not entirely sure it's used. My understanding could be totally wrong, and if so I'll politely ask Paul or anyone else to hit me with a cluebat :). AFAIK, the reason is to be able to build multiple bootwrapper configurations around a single kernel image without multiple compiles of the wrapper bits, and to increase the amount of compile testing that all the wrapper bits are subjected to. (this way they get compiled on all PowerPC kernel compiles instead of just when they are needed for an obscure platform) g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
On Tue, Jun 24, 2008 at 03:07:48PM -0600, John Linn wrote: Hi Grant, It appears that you designed the simpleImage around Xilinx FPGAs. Yes. Since we have to initialize the 16550 UART in the bootstrap and there's no boot loader, were you thinking we would add the 16550 initialization to simpleboot.c? Yes; or at least break out the common routine to be called by all simpleImage targets and have a virtex-specific 'frontend' to it called simpleboot-virtex405.c. Why do we want a flat binary rather than an elf file for the target? 'Cause a flat binary can be loaded anywhere in RAM and is smaller than an ELF image (no headers). g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
John == John Linn [EMAIL PROTECTED] writes: Hi John, +config PPC_FPU + depends on XILINX_VIRTEX_5_FXT + bool Enable Xilinx Soft FPU + help +This option enables the Xilinx Soft FPU attached to the APU +interface of the PPC440 (requires DP_FULL FPU pcore). There is already a PPC_FPU option in platforms/Kconfig.cputype Is the Xilinx soft FPU compatible with the normal powerpc FPU? -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
Yes it is compatible with the normal powerpc FPU. Thanks, John -Original Message- From: Peter Korsgaard [mailto:[EMAIL PROTECTED] On Behalf Of Peter Korsgaard Sent: Tuesday, June 24, 2008 12:46 AM To: John Linn Cc: Josh Boyer; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support John == John Linn [EMAIL PROTECTED] writes: Hi John, +config PPC_FPU + depends on XILINX_VIRTEX_5_FXT + bool Enable Xilinx Soft FPU + help +This option enables the Xilinx Soft FPU attached to the APU +interface of the PPC440 (requires DP_FULL FPU pcore). There is already a PPC_FPU option in platforms/Kconfig.cputype Is the Xilinx soft FPU compatible with the normal powerpc FPU? -- Bye, Peter Korsgaard This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
John == John Linn [EMAIL PROTECTED] writes: John Yes it is compatible with the normal powerpc FPU. Ahh, great - That didn't used to be the case with the earlier fpu stuff afaik. -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
I put in a link to the Xilinx FPU documentation that describes it. http://www.xilinx.com/support/documentation/ip_documentation/apu_fpu_vir tex5.pdf Thanks, John -Original Message- From: Peter Korsgaard [mailto:[EMAIL PROTECTED] On Behalf Of Peter Korsgaard Sent: Tuesday, June 24, 2008 8:02 AM To: John Linn Cc: Josh Boyer; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support John == John Linn [EMAIL PROTECTED] writes: John Yes it is compatible with the normal powerpc FPU. Ahh, great - That didn't used to be the case with the earlier fpu stuff afaik. -- Bye, Peter Korsgaard This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
Hi Grant, It appears that you designed the simpleImage around Xilinx FPGAs. Since we have to initialize the 16550 UART in the bootstrap and there's no boot loader, were you thinking we would add the 16550 initialization to simpleboot.c? Why do we want a flat binary rather than an elf file for the target? Thanks, John From Grant's commit: This target produces a flat binary rather than an ELF file, fixes the entry point at the beginning of the image, and takes a complete device tree with no fixups needed. -Original Message- From: Josh Boyer [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 7:36 PM To: John Linn Cc: linuxppc-dev@ozlabs.org Subject: Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support On Mon, 23 Jun 2008 15:30:35 -0600 John Linn [EMAIL PROTECTED] wrote: + * + * Copyright 2007 IBM Corporation + * Based on cuboot-83xx.c, which is: + * Copyright (c) 2007 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include stddef.h +#include stdio.h +#include ops.h +#include dcr.h +#include 4xx.h +#include io.h +#include reg.h + +BSS_STACK(4096); + +#include types.h +#include gunzip_util.h +#include libfdt.h +#include ../../../include/linux/autoconf.h Ew. We've never included the CONFIG_ variables from Kconfig in the bootwrapper. It's supposed to be independent of the kernel. I'll try to better understand if we can detect the compressed device tree and if we really have to disable the APU. What's the reasoning for being independent of the kernel, maybe it's obvious to everyone but me? The intention, as I understand it, is that the wrapper utilities can be installed stand-alone and used to wrap other kernels if needs be. In practice I've not seen this happen yet, as most PowerPC kernels are built directly from the kernel source. Fedora does have a separate package for the wrapper bits, but I'm not entirely sure it's used. My understanding could be totally wrong, and if so I'll politely ask Paul or anyone else to hit me with a cluebat :). josh This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
On Mon, 23 Jun 2008 10:28:53 -0600 John Linn [EMAIL PROTECTED] wrote: This is an early patch against the mainline that I wanted to start getting comments on. I would appreciate any feedback. I already see a few things that I need to look into myself. 1.I'm not sure why we need to disable the interrupts in the bootstrap loader? 2.I see some SecetLab copyright in new files that might be just a cut/paste type error. 3.I don't see the cputable.c up to date with the Xilinx specific 440. Your patch got pretty word-wrapped because of the forward. I'll give it a go though. diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 3934e26..94adfe1 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -483,6 +483,81 @@ config SECCOMP If unsure, say Y. Only embedded should say N here. +config WANT_DEVICE_TREE + bool + default n Not sure why you added this back. We removed it entirely recently. +config BUILD_RAW_IMAGE + bool Build firmware-independent image + select WANT_DEVICE_TREE + help + If this is enabled, a firmware independent raw image will be + built, as zImage.raw. This requires a completely filled-in + device tree, with the following labels: + + mem_size_cells: on /#address-cells + memsize: on the size portion of /memory/reg + timebase: on the boot CPU's timebase property + +config DEVICE_TREE + string Static device tree source file + depends on WANT_DEVICE_TREE + help + This specifies the device tree source (.dts) file to be + compiled and included when building the bootwrapper. If a + relative filename is given, then it will be relative to + arch/powerpc/boot/dts. If you are not using the bootwrapper, + or do not need to build a dts into the bootwrapper, this + field is ignored. + + For example, this is required when building a cuImage target + for an older U-Boot, which cannot pass a device tree itself. + Such a kernel will not work with a newer U-Boot that tries to + pass a device tree (unless you tell it not to). If your U-Boot + does not mention a device tree in help bootm, then use the + cuImage target and specify a device tree here. Otherwise, use + the uImage target and leave this field blank. This doesn't seem like it's needed any longer either. I'm confused why these changes were added back in (and similar the Makefile changes.) +config COMPRESSED_DEVICE_TREE + bool Use compressed device tree + depends on XILINX_VIRTEX + depends on WANT_DEVICE_TREE + help + In Xilinx FPGAs, the hardware can change quite dramatically while + still running the same kernel. In this case and other similar + ones, it is preferable to associate the device tree with a + particular build of the hardware design. This configuration + option assumes that the device tree blob has been compressed and + stored in Block RAM in the FPGA design. Typically, such a block + ram is available in order to provide a bootloop or other code + close to the reset vector at the top of the address space. By + default, the parameter options associated with this configuration + assumes that exactly one block ram (2KB) of storage is available, + which should be sufficient for most designs. If necessary in a + particular design, due to boot code requirement or a large number + of devices, this address (and the corresponding parameters in the + EDK design) must be modified. + + Note that in some highly area constrained designs, no block rams + may be available in the design, and some other mechanism may be + used to hold the processor in reset while external memory is + initialized with processor code. In such cases, that mechanism + should also be used to load the device tree at an appropriate + location, and the parameters associated with this configuration + option should be modified to point to that location in external + memory. + +config COMPRESSED_DTB_START + hex Start of compressed device tree + depends on COMPRESSED_DEVICE_TREE + default 0xf800 + +config COMPRESSED_DTB_SIZE + hex Size of compressed device tree + depends on COMPRESSED_DEVICE_TREE + default 0x800 + + endmenu config ISA_DMA_API snip diff --git a/arch/powerpc/boot/dts/ml507.dts b/arch/powerpc/boot/dts/ml507.dts new file mode 100644 index 000..43d8535 --- /dev/null +++ b/arch/powerpc/boot/dts/ml507.dts @@ -0,0 +1,254 @@ +/* + * (C) Copyright 2007-2008 Xilinx, Inc. + * (C) Copyright 2007 Michal Simek + * + * Michal SIMEK [EMAIL PROTECTED] + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public
RE: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3934e26..94adfe1 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -483,6 +483,81 @@ config SECCOMP
If unsure, say Y. Only embedded should say N here.
+config WANT_DEVICE_TREE
+ bool
+ default n
Not sure why you added this back. We removed it entirely recently.
This should go.. Generally speaking, we need to cleanup the 405 and 440
code to play nice with the new boot code structure.
+config COMPRESSED_DEVICE_TREE
+ bool Use compressed device tree
+ depends on XILINX_VIRTEX
+ depends on WANT_DEVICE_TREE
+ help
+ In Xilinx FPGAs, the hardware can change quite dramatically
while
+ still running the same kernel. In this case and other similar
+ ones, it is preferable to associate the device tree with a
+ particular build of the hardware design. This configuration
+ option assumes that the device tree blob has been compressed
and
+ stored in Block RAM in the FPGA design. Typically, such a
block
+ ram is available in order to provide a bootloop or other code
+ close to the reset vector at the top of the address space. By
+ default, the parameter options associated with this
configuration
+ assumes that exactly one block ram (2KB) of storage is
available,
+ which should be sufficient for most designs. If necessary in
a
+ particular design, due to boot code requirement or a large
number
+ of devices, this address (and the corresponding parameters in
the
+ EDK design) must be modified.
+
+ Note that in some highly area constrained designs, no block
rams
+ may be available in the design, and some other mechanism may
be
+ used to hold the processor in reset while external memory is
+ initialized with processor code. In such cases, that
mechanism
+ should also be used to load the device tree at an appropriate
+ location, and the parameters associated with this
configuration
+ option should be modified to point to that location in
external
+ memory.
+
+config COMPRESSED_DTB_START
+ hex Start of compressed device tree
+ depends on COMPRESSED_DEVICE_TREE
+ default 0xf800
+
+config COMPRESSED_DTB_SIZE
+ hex Size of compressed device tree
+ depends on COMPRESSED_DEVICE_TREE
+ default 0x800
+
+
This needs to get added for 405 too. More likely its easier to generate
a separate patch for this.
+
+/ {
+ #address-cells = 1;
This doesn't look right. 440 has 36-bit physical addresses, so
#address-cells should be 2.
In Virtex FPGAs, the 440 is only hooked up through a 32-bit bus.
+ #size-cells = 1;
+ compatible = xlnx,virtex;
+ dcr-parent = ppc440_virtex5_0;
+ model = testing;
+ chosen {
+ bootargs = console=ttyS0 ip=on root=/dev/ram;
+ linux,stdout-path = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
+ } ;
+ cpus {
+ #address-cells = 1;
+ #cpus = 1;
+ #size-cells = 0;
+ ppc440_virtex5_0: [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
You don't need those in the cpu node itself.
I'll take care of removing them.
+ clock-frequency = 17d78400;
+ compatible = PowerPC,440, ibm,ppc440;
+ d-cache-line-size = 20;
+ d-cache-size = 8000;
+ dcr-access-method = native;
+ dcr-controller ;
+ device_type = cpu;
+ i-cache-line-size = 20;
+ i-cache-size = 8000;
+ model = PowerPC,440;
+ reg = 0;
+ timebase-frequency = 17d78400;
+ xlnx,apu-control = 1;
+ xlnx,apu-udi-0 = c07701;
+ xlnx,apu-udi-1 = c47701;
+ xlnx,apu-udi-10 = 0;
+ xlnx,apu-udi-11 = 0;
+ xlnx,apu-udi-12 = 0;
+ xlnx,apu-udi-13 = 0;
+ xlnx,apu-udi-14 = 0;
+ xlnx,apu-udi-15 = 0;
+ xlnx,apu-udi-2 = 0;
+ xlnx,apu-udi-3 = 0;
+ xlnx,apu-udi-4 = 0;
+ xlnx,apu-udi-5 = 0;
+ xlnx,apu-udi-6 = 0;
+ xlnx,apu-udi-7 = 0;
+ xlnx,apu-udi-8 = 0;
+ xlnx,apu-udi-9 = 0;
+ xlnx,dcr-autolock-enable = 1;
+ xlnx,dcu-rd-ld-cache-plb-prio = 0;
+ xlnx,dcu-rd-noncache-plb-prio = 0;
+ xlnx,dcu-rd-touch-plb-prio = 0;
+ xlnx,dcu-rd-urgent-plb-prio = 0;
+ xlnx,dcu-wr-flush-plb-prio = 0;
+
RE: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
Thanks for the comments Josh.
I commented on the others that Stephen didn't comment on.
diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
index ccaedae..ec57ec9 100644
--- a/arch/powerpc/boot/io.h
+++ b/arch/powerpc/boot/io.h
@@ -99,4 +99,11 @@ static inline void barrier(void)
asm volatile( : : : memory);
}
+static inline void disable_irq(void)
+{
+int dummy;
+asm volatile(mfmsr %0; rlwinm %0, %0, 0, ~(115); mtmsr %0 :
+ =r (dummy) : : memory);
+}
As you said, figuring out why this is here and at least adding a
comment would be good.
Agreed.
#endif /* _IO_H */
diff --git a/arch/powerpc/boot/virtex.c b/arch/powerpc/boot/virtex.c
new file mode 100644
index 000..5d807c6
--- /dev/null
+++ b/arch/powerpc/boot/virtex.c
@@ -0,0 +1,246 @@
+/*
+ * Old U-boot compatibility for Walnut
+ *
+ * Author: Josh Boyer [EMAIL PROTECTED]
You can remove this. I'm pretty sure I didn't write this file :)
Agreed ;)
+ *
+ * Copyright 2007 IBM Corporation
+ * Based on cuboot-83xx.c, which is:
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
modify
it
+ * under the terms of the GNU General Public License version 2 as
published
+ * by the Free Software Foundation.
+ */
+
+#include stddef.h
+#include stdio.h
+#include ops.h
+#include dcr.h
+#include 4xx.h
+#include io.h
+#include reg.h
+
+BSS_STACK(4096);
+
+#include types.h
+#include gunzip_util.h
+#include libfdt.h
+#include ../../../include/linux/autoconf.h
Ew. We've never included the CONFIG_ variables from Kconfig in the
bootwrapper. It's supposed to be independent of the kernel.
I'll try to better understand if we can detect the compressed device
tree and if we really have to disable the APU.
What's the reasoning for being independent of the kernel, maybe it's
obvious to everyone but me?
+#define UART_DLL0 /* Out: Divisor Latch Low */
+#define UART_DLM1 /* Out: Divisor Latch High */
+#define UART_FCR2 /* Out: FIFO Control Register */
+#define UART_FCR_CLEAR_RCVR 0x02/* Clear the RCVR FIFO
*/
+#define UART_FCR_CLEAR_XMIT 0x04/* Clear the XMIT FIFO */
+#define UART_LCR3 /* Out: Line Control Register */
+#define UART_MCR4 /* Out: Modem Control Register
*/
+#define UART_MCR_RTS0x02/* RTS complement */
+#define UART_MCR_DTR0x01/* DTR complement */
+#define UART_LCR_DLAB 0x80/* Divisor latch access
bit */
+#define UART_LCR_WLEN8 0x03/* Wordlength: 8 bits */
+
+/* This function is only needed when there is no boot loader to
+ initialize the UART
+*/
+static int virtex_ns16550_console_init(void *devp)
+{
+int n;
+unsigned long reg_phys;
+unsigned char *regbase;
+u32 regshift, clk, spd;
+u16 divisor;
+
+n = getprop(devp, virtual-reg, regbase, sizeof(regbase));
+if (n != sizeof(regbase)) {
+if (!dt_xlate_reg(devp, 0, reg_phys, NULL))
+return -1;
+
+regbase = (void *)reg_phys + 3;
+}
+regshift = 2;
+
+n = getprop(devp, current-speed, (void *)spd, sizeof(spd));
+if (n != sizeof(spd))
+spd = 9600;
+
+/* should there be a default clock rate?*/
+n = getprop(devp, clock-frequency, (void *)clk, sizeof(clk));
+if (n != sizeof(clk))
+return -1;
+
+divisor = clk / (16 * spd);
+
+/* Access baud rate */
+out_8(regbase + (UART_LCR regshift), UART_LCR_DLAB);
+
+/* Baud rate based on input clock */
+out_8(regbase + (UART_DLL regshift), divisor 0xFF);
+out_8(regbase + (UART_DLM regshift), divisor 8);
+
+/* 8 data, 1 stop, no parity */
+out_8(regbase + (UART_LCR regshift), UART_LCR_WLEN8);
+
+/* RTS/DTR */
+out_8(regbase + (UART_MCR regshift), UART_MCR_RTS |
UART_MCR_DTR);
+
+/* Clear transmitter and receiver */
+out_8(regbase + (UART_FCR regshift),
+UART_FCR_CLEAR_XMIT |
UART_FCR_CLEAR_RCVR);
+return 0;
+}
+
+/* For virtex, the kernel may be loaded without using a bootloader
and
if so
+ some UARTs need more setup than is provided in the normal console
init
+*/
+static int virtex_serial_console_init(void)
+{
+void *devp;
+char devtype[MAX_PROP_LEN];
+char path[MAX_PATH_LEN];
+
+devp = finddevice(/chosen);
+if (devp == NULL)
+return -1;
+
+if (getprop(devp, linux,stdout-path, path, MAX_PATH_LEN) 0)
{
+devp = finddevice(path);
+if (devp == NULL)
+return -1;
+
+if ((getprop(devp, device_type, devtype,
sizeof(devtype)) 0)
+ !strcmp(devtype, serial)
+ (dt_is_compatible(devp, ns16550)))
+
Re: [PATCH] [RFC] powerpc: Xilinx: adding virtex5 powerpc 440 support
On Mon, 23 Jun 2008 15:30:35 -0600 John Linn [EMAIL PROTECTED] wrote: + * + * Copyright 2007 IBM Corporation + * Based on cuboot-83xx.c, which is: + * Copyright (c) 2007 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include stddef.h +#include stdio.h +#include ops.h +#include dcr.h +#include 4xx.h +#include io.h +#include reg.h + +BSS_STACK(4096); + +#include types.h +#include gunzip_util.h +#include libfdt.h +#include ../../../include/linux/autoconf.h Ew. We've never included the CONFIG_ variables from Kconfig in the bootwrapper. It's supposed to be independent of the kernel. I'll try to better understand if we can detect the compressed device tree and if we really have to disable the APU. What's the reasoning for being independent of the kernel, maybe it's obvious to everyone but me? The intention, as I understand it, is that the wrapper utilities can be installed stand-alone and used to wrap other kernels if needs be. In practice I've not seen this happen yet, as most PowerPC kernels are built directly from the kernel source. Fedora does have a separate package for the wrapper bits, but I'm not entirely sure it's used. My understanding could be totally wrong, and if so I'll politely ask Paul or anyone else to hit me with a cluebat :). josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
