Re: Is anyone using the C67x00 USB Host ?
Worked out the interrupt problem - the FPGA parameters for the USB interrupt were wrong. But I still can not get host 1B working. Any sugestions as to something I can look at ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Is anyone using the C67x00 USB Host ?
Peter Korsgaard wrote: David But I still can not get host 1B working. Any sugestions as to David something I can look at ? Not right away. All the platforms I have been using have only used port 1A, so there could potentially be a mistake in the driver / firmware. Thanks, even knowing that helps. I have spent most of this morning soldering a wirewraped USB connector to my board. If the interrupt firware was wrong, maybe somebody switched D+ and D- or maybe I can connect to 2a and use it as a 2nd host. Unfortunately no joy. As best as I can tell the USB system is finding 1A,1B, amd 2A - ls /dev/usbdev* lists usbdev1.1 usbdev1.1_ep00 usbdev1.1_ep81 usbdev1.2 usbdev1.2_ep00 usbdev1.2_ep01 usbdev1.2_ep81 usbdev2.1 usbdev2.1_ep00 usbdev2.1_ep81 How about anybody used 2A or 2B ? Anybody know of a Xilinx/Cypres test app that tests hosts on anything but 1A ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Is anyone using the C67x00 USB Host ?
Michal; I tried the address swap you mentioned. That made things much worse. I have also tried changing hpi_regstep from 4 to 1 2 with zero change in behavior - which does not make sense to me. The logs below are using a Toshiba 2G thumb drive moved between host 1 and host 2. I have also tried a 3com KAWETH based USB NIC. In all instances with the IRQ disabled and a timer in its place, I can detect anything that I have drivers for on host 1 but not on host 2. in all cases enabling the IRQ causes either register dumps or sprays the console with messages about unhandled IRQ's or both. I have some logs below First - this is the log of a boot with the IRQ enabled. Linux version 2.6.26-rc4-dirty (r...@hp-dhlii.dlasys.lcl) (gcc version 4.2.4) #9 Thu Dec 11 18:03:34 EST 2008 Pico Virtex-4 port Port by DLA Systems (i...@dlasys.net) Zone PFN ranges: DMA 0 -65535 Normal 65535 -65535 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -65535 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65023 Kernel command line: root=/dev/ram IP=172.16.0.154 Xilinx INTC #0 at 0x4120 mapped to 0xF5FFB000 PID hash table entries: 1024 (order: 10, 4096 bytes) console [ttyUL0] enabled Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 253952k available (1788k kernel code, 812k data, 3036k init, 0k highmem) Mount-cache hash table entries: 512 net_namespace: 192 bytes NET: Registered protocol family 16 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered io scheduler noop registered (default) Serial: Pico Xilinx uartlite driver $Revision: 0.10 $ 1 ports ttyUL0 at MMIO 0x4060 (irq = 15) is a uartlite brd: module loaded xilinx_lltemac.c:v0.10a Dec 11 2008 Yoshio Kashiwagi : temac addr d000 base 81c0 len 128 : sdma addr d0002100 base 84600100 len 128 : temac IRQ tx 0 rx 1 phy 2 fifo 255 : xilinx_lltemac.c:v Dec 11 2008 Yoshio Kashiwagi : temac_set_mac_address(00:50:C2:44:28:14) eth0: Dropping NETIF_F_SG since no checksum feature. eth0: ll_temac at d000,0 IRQ 1 MAC:00:50:C2:44:28:14 usbcore: registered new interface driver kaweth pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver usbcore: registered new interface driver pegasus Driver 'sd' needs updating - please use bus_type methods usbmon: debugfs is not available irq 14: nobody cared (try booting with the irqpoll option) Call Trace: [cf81fb40] [c00091bc] show_stack+0x44/0x1ac (unreliable) [cf81fb80] [c0044718] __report_bad_irq+0x34/0xb8 [cf81fba0] [c0044a14] note_interrupt+0x278/0x2cc [cf81fbd0] [c0043ca4] __do_IRQ+0x100/0x118 [cf81fbf0] [c00075d8] do_IRQ+0xbc/0xc0 [cf81fc00] [c0002f54] ret_from_except+0x0/0x14 [cf81fcc0] [] 0x0 [cf81fce0] [c000735c] do_softirq+0x58/0x5c [cf81fcf0] [c00253bc] irq_exit+0x48/0x58 [cf81fd00] [c0007588] do_IRQ+0x6c/0xc0 [cf81fd10] [c0002f54] ret_from_except+0x0/0x14 [cf81fdd0] [c00443fc] setup_irq+0x1c4/0x23c [cf81fdf0] [c0044538] request_irq+0xc4/0xd8 [cf81fe20] [c01bbac8] c67x00_drv_probe+0x118/0x3e4 [cf81fe50] [c00fdc20] platform_drv_probe+0x20/0x30 [cf81fe60] [c00fcc9c] driver_probe_device+0xbc/0x1f4 [cf81fe80] [c00fce58] __driver_attach+0x84/0x88 [cf81fea0] [c00fc1a4] bus_for_each_dev+0x5c/0x98 [cf81fed0] [c00fcaa0] driver_attach+0x24/0x34 [cf81fee0] [c00fc6d8] bus_add_driver+0xb4/0x248 [cf81ff10] [c00fd068] driver_register+0x5c/0x158 [cf81ff30] [c00fdfcc] platform_driver_register+0x9c/0xac [cf81ff40] [c024c188] c67x00_init+0x18/0x28 [cf81ff50] [c023b1a0] kernel_init+0x98/0x27c [cf81fff0] [c0004b18] kernel_thread+0x44/0x60 handlers: [c013f28c] (c67x00_irq+0x0/0x128) Disabling IRQ #14 [ cut here ] Badness at c013fd58 [verbose debug info unavailable] NIP: c013fd58 LR: c013fd4c CTR: c0019a6c REGS: cf81fd50 TRAP: 0700 Not tainted (2.6.26-rc4-dirty) MSR: 8030 EE,IR,DR CR: 3533 XER: e000 TASK = cf814c00[1] 'swapper' THREAD: cf81e000 GPR00: 0001 cf81fe00 cf814c00 c0222520 cf814028 01f4 0001 GPR08: 0008 00200200 cf8496f8 cf8496f8 3533 b6b4 c01eab48 c01eab00 GPR16: c01eab70 c01eab30 cf81ff98 c0253124 c025 0701 c025 GPR24: cf81ff58 c0223888 c0223758 cf8496e8 c0223558 cf8496e0 NIP [c013fd58] c67x00_ll_reset+0x48/0x88 LR [c013fd4c] c67x00_ll_reset+0x3c/0x88 Call Trace: [cf81fe00] [c013fd4c] c67x00_ll_reset+0x3c/0x88 (unreliable) [cf81fe20] [c01bbb4c] c67x00_drv_probe+0x19c/0x3e4 [cf81fe50]
Re: Is anyone using the C67x00 USB Host ?
More info. there are 3 USB connectors on this board Host 1 - SIE1a Host 2 - SIE1b Peripheral 1 SIE2a At the moment I do nto care about Peripheral 1. I am virtually certain A0 and A1 are not switched. with no USB devices plugged in The status port is returning a value of 0x30 if I read it immediately after iomapping the device. It returns a value of 0x20 after calling c67x00_ll_init() and c67x00_ll_hpi_reg_init() The instant request_irq() is called before a single subsequent line in the driver executes c67x00_irq() is called. at that point c67x00_ll_hpi_status(c67x00); returns 0x20 the remainder of the interrupt handle is called and the status changes to 0x0 - and remains there. Howevr USB interrupts continue to occur until the kernel gets ticked and turns them off. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dh...@dlasys.net http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Is anyone using the C67x00 USB Host ?
Peter Korsgaard wrote: David == David H Lynch [EMAIL PROTECTED] writes: Hi, David I am having two problems with it. David I can not get it working with interrupts, No activity on the interrupt pin or is it always active? Neither: The USB system does not function with interrupts, and the kernel reports lots of unhandled IRQ's. I beleive that int_status = c67x00_ll_hpi_status(c67x00); if (!int_status) return IRQ_NONE; is always exiting IRQ_NONE; If I replace the request_irq() call with installation of a timer service routine that basically periodically calls the interrupt handler, everything works fine - albeit slowly. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Is anyone using the C67x00 USB Host ?
Michal Simek wrote: Hi David, currently I am working on backport this driver to 2.6.20 to Microblaze but a lot of things are the same. From HW site. Interrupt goes outside of IP directly to interrupt controller. And you need to call platform_device_register with proper structure. Could you send your kernel log? I can post a log, but: Interrupts are occuring, and being trapped. The following code in the driver just seems to always return IRQ_NONE when called from an interrupt. int_status = c67x00_ll_hpi_status(c67x00); if (!int_status) return IRQ_NONE; However, if I add a timer that just polls the interrupt handler, I have the driver working (on the first port) but slowly. Thanks, Michal -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Is anyone using the C67x00 USB Host ?
I am having two problems with it. I can not get it working with interrupts, I can not get the 2nd USB port working. If someone has it working I would appreciate knowing. Thanks -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
C67x00 USB problems
Good news - works. Bad news - sort of. I am using the C67x00_HCD driver from 2.6.24 mainline. If I kill off installing the interrupt handler and just poll it. I can get the first port working - fairly slowly. If I enable the interrupt handler I get lots of messages from the Kernel about unhandled IRQ's and then the Kernel disables the IRQ. Although sometimes I just get a kernel panic when loading the driver. The only way out of the irq handler without handling the IRQ is // printk(KERN_ERR c67x00_irq()00\n); int_status = c67x00_ll_hpi_status(c67x00); if (!int_status) return IRQ_NONE; But if that is failing then why are things working when polled ? Clues would be greatly appreciated ? Is there any interest in a patch to support polling the USB driver ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
C67x00 USB problems II
Issue # 2
how do I get the 2nd port working ?
I have the platform data altered as follows:
.dev.platform_data = (struct c67x00_platform_data) {
.sie_config = C67X00_SIE1_HOST | C67X00_SIE2_HOST,
.hpi_regstep= 0x04,
/* A0 not connected on 16bit bus */
},
For two hosts rather than a host and a peripheral.
I have been pretending I can get this working without getting too
intimate with USB or this driver. Apparently that has been a self-delusion.
Again clues greatly appreciated.
--
Dave Lynch DLA Systems
Software Development:Embedded Linux
717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net
fax: 1.253.369.9244Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.
Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction.
Albert Einstein
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 EthernetNIC
John Linn wrote: What about you getting all the review testing done and then we (Xilinx) will add the OF support to the driver? I doubt the powerpc mainline will take the driver without OF support. In fact, we had to remove the platform bus support from the last driver that we put into mainline for arch/powerpc. That is perfectly fine with me. i will try to pull the xilinx git tree and see how much closer I can make the probe so that converting will be easier. xilinx_lltemac is the preferred. I don't think using xilinx_lltemac should cause problems. Our Xilinx Git tree has a xilinx_lltemac subdir that contains the non-flat driver but that should be ok with your xilinx_lltemac.c file in the net directory. The next patch incarnation will have everything as xilinx_lltemac - including the file as xilinx_lltemac.c -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 Ethernet NIC
Please bear with me. This is my first patch submission.
Grant Likely of Secret Labs has kindly done a prelimary view.
Hopefully I have correct the issues he raised.
Ethernet driver for Xilinx LL TEMAC
Original Author Yoshio Kashiwagi
Updated and Maintained by David Lynch
Signed-off-by: David H. Lynch Jr [EMAIL PROTECTED]
---
drivers/net/Kconfig|5
drivers/net/Makefile |1
drivers/net/xps_lltemac.c | 1283
include/linux/xilinx_devices.h |2
4 files changed, 1290 insertions(+), 1 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index fd0dd80..71a3eee 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2332,6 +2332,11 @@ config MV643XX_ETH
Some boards that use the Discovery chipset are the Momenco
Ocelot C and Jaguar ATX and Pegasos II.
+config XPS_LLTEMAC
+ tristate Xilinx LLTEMAC 10/100/1000 Ethernet MAC driver
+ help
+ This driver supports the Xilinx 10/100/1000 LLTEMAC found in Virtex
4 FPGAs
+
config QLA3XXX
tristate QLogic QLA3XXX Network Driver Support
depends on PCI
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 1f09934..9196bab 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -126,6 +126,7 @@ obj-$(CONFIG_AX88796) += ax88796.o
obj-$(CONFIG_TSI108_ETH) += tsi108_eth.o
obj-$(CONFIG_PICO_TEMAC) += pico_temac.o
obj-$(CONFIG_MV643XX_ETH) += mv643xx_eth.o
+obj-$(CONFIG_XPS_LLTEMAC) += xps_lltemac.o
obj-$(CONFIG_QLA3XXX) += qla3xxx.o
obj-$(CONFIG_PPP) += ppp_generic.o
diff --git a/drivers/net/xps_lltemac.c b/drivers/net/xps_lltemac.c
new file mode 100644
index 000..1f2c158
--- /dev/null
+++ b/drivers/net/xps_lltemac.c
@@ -0,0 +1,1283 @@
+/*==
+
+ Driver for Xilinx temac ethernet NIC's
+
+ Author: Yoshio Kashiwagi
+ Copyright (c) 2008 Nissin Systems Co.,Ltd.
+
+ Revisons: David H. Lynch Jr. [EMAIL PROTECTED]
+ Copyright (C) 2005-2008 DLA Systems
+
+==*/
+
+#define DRV_NAMExilinx_lltemac
+#define DRV_AUTHOR Yoshio Kashiwagi
+#define DRV_EMAIL
+
+#include linux/module.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/init.h
+#include linux/skbuff.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+
+#include linux/mii.h
+#include linux/in.h
+#include linux/pci.h
+
+#include linux/ip.h
+#include linux/tcp.h /* just needed for sizeof(tcphdr) */
+#include linux/udp.h /* needed for sizeof(udphdr) */
+#include asm/delay.h
+#include asm/io.h
+
+/* register access modes */
+typedef enum { REG_DCR = 1, REG_IND, REG_DIR} REG_MODE;
+
+#define MII_ANI 0x10
+#define PHY_NUM 0
+#define PHY_TIMEOUT 1
+
+#define MII_SSR 0x11
+#define MII_SSR_LINK(1 10)
+#define MII_SSR_SPDMASK 0xC000
+#define MII_SSR_SPD1000 (1 15)
+#define MII_SSR_SPD100 (1 14)
+#define MII_SSR_SPD10 0
+#define MII_SSR_FD (1 13)
+
+#define MII_ISR 0x13
+
+/* packet size info */
+#define XTE_MTU 1500/* max MTU size of
Ethernet frame */
+#define XTE_HDR_SIZE14 /* size of Ethernet
header */
+#define XTE_TRL_SIZE4 /* size of Ethernet
trailer (FCS) */
+#define XTE_MAX_FRAME_SIZE (XTE_MTU + XTE_HDR_SIZE + XTE_TRL_SIZE)
+#define XTE_JUMBO_MTU 9000
+#define XTE_MAX_JUMBO_FRAME_SIZE(XTE_JUMBO_MTU + XTE_HDR_SIZE +
XTE_TRL_SIZE)
+
+/** Configuration options
+ *
+ * Device configuration options. See the temac_setoptions(),
+ * XTemac_ClearOptions() and XTemac_GetOptions() for information on how
to use
+ * options.
+ *
+ * The default state of the options are noted and are what the device
and driver
+ * will be set to after calling XTemac_Reset() or XTemac_Initialize().
+ *
+ */
+
+#define XTE_OPTION_PROMISC (1 0)/** Accept
all incoming packets. This option defaults to disabled (cleared) */
+#define XTE_OPTION_JUMBO(1 1)/** Jumbo
frame support for Tx Rx. This option defaults to disabled (cleared) */
+#define XTE_OPTION_VLAN (1 2)/** VLAN
Rx Tx frame support. This option defaults to disabled (cleared) */
+#define XTE_OPTION_FLOW_CONTROL (1 4)/** Enable
recognition of flow control frames on Rx This option defaults to enabled
(set) */
+#define XTE_OPTION_FCS_STRIP(1 5)/** Strip
FCS and PAD from incoming frames. Note: PAD from VLAN frames is not
stripped. This option defaults to disabled (set) */
+#define XTE_OPTION_FCS_INSERT (1 6)/**
Generate FCS field and add PAD automatically for outgoing
Re: FW: Error occured when appended FPGA image in the section of .init.text then bootup
Is there some reason this patch is not getting pushed into mainline ? Alan Nishioka wrote: 朱利达 wrote: The request below give rise to the problem. I have some boards equiped with MPC8247 and FPGA without storage media which used as a PCI interface. So when the linux bootup before initialize the PCI, the code of FPGA will download. I append the FPGA code file in the Kernel section '.init.text'. when linux bootup firstly it check the board type(different board type would download different code), and download fpga code. More board types lead to more FPGA code. I append them all in the section of '.init.text'. when the total size of the code reach out 2M. The error occured. I read the '__log_buf' the kernel access some bad area. As the powerpce603 will map 16M address use two bat, how and why the problem occured, and how to solved it . Since the error occurs at 2M, I am going to guess it is similar to problem I had. The default link/load address for booting is 0x20. Here is a link: http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=14717 This fix is for the arch/ppc tree. I don't know if the arch/powerpc tree works the same way. In the future, you should say what kernel version you are using and what the error was. Alan Nishioka [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Error occured when appended FPGA image in the section of .init.text then bootup
I do not think the patch in question is board specific. It has been arround for a long time. And I think alot of people have been bitten by the problem. It is required for my board. I think it is required for any board that generates a large enough image. I would be happy to signoff on it - it works/is necescary on my board. I can not seem to find the same code in arch/powerpc so I have no clue whether something similar might be needed there. Josh Boyer wrote: On Sat, 31 May 2008 13:07:53 -0400 David H. Lynch Jr. [EMAIL PROTECTED] wrote: Is there some reason this patch is not getting pushed into mainline ? Lacks Signed-off-by, support for the board in question doesn't even exist in arch/ppc anymore, and arch/ppc is going away in June. josh -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Cross toolchain for ppc405 (virtex-4)
I am not sure if this answers your question but to build a 2.6 Linux kernel using the buildroot uclibc ppc cross compiler you would issue the following make command make ARCH=ppc CROSS_COMPILE=powerpc-linux-uclibc- If you were using the crosstools compiler rather than buildroot, the CROSS_COMPILE value would change. For older version of GCC it might require a full path to the crosscompiler. If you are building a BSP in the powerpc tree use ARCH=powerpc I am fairly certain that when you are building a Linux kernel it is irrelevant whether you use a glibc or uclibc or ... compiler. The kernel is not going to link against any standard C library, those library functions the kernel uses must be coded in the kernel. However, when you are cross compiling applications for your target it is a good idea to stick to the same standard C library and associated cross compiler. rodolfo wrote: I'm sorry. I want build kernel linux 2.6 for ml403. Did I have to change the predefined compiler flags for ppc_4xx? The default value is -mcpu=403. On Wed, 28 May 2008 13:32:51 -0600, John Linn [EMAIL PROTECTED] wrote: I don't know, I'm not familiar with what you are doing and it's not clear from the message. -- John -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
APU FPU in Virtex ppc405
Were the issues associated with getting the Xilinx Floating point APU working with Linux completely resolved ? Is there a git tree or patch collection with the appropriate patches etc ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx PowerPC
I am preparing my own version of Yoshio's driver. Since most of my changes are re-ordering, renaming, or other items of small consequence, I will leave Yoshio as the author - unless he prefers otherwise. I hope to have it ready to submit as a patch in a few days. If Yoshio is unhappy with any of the changes I have made or chooses to submit his original code or some permutation I will withdrawl mine. While adding OF checksum offloading, ... would be nice, All I am looking to do is get something that can start its way into the kernel. This driver is working for me - with very light testing so far. If no one else is willing to Shepard something in, then I will try. Hints, clues, etc would be very much appreciated. I presume that if this driver is acceptable here, the next step would be forwarding it to linux-netdev ? Yoshio Kashiwagi wrote: David-san, This driver must add some corrections, for example, Checksum-offloading is incomplete as you say it. As for me, it is very happy to obtain your cooperation. Let me know if I can be of any work for it. Moreover, although I wrote the xps_ll_temac driver for u-boot of a very simple single SDMA descriptor, I have not got used and put in the contribution way. Best Regards, Yoshio Kashiwagi - Nissin Systems -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx PowerPC
, 0x10220483);
//sdma_reg_write(lp, TX_CHNL_CTRL, 0x00100483);
sdma_reg_write(lp, RX_CHNL_CTRL, 0xff010283);
sdma_reg_write(lp, RX_CURDESC_PTR, (unsigned int)cdmac_rx_bd_phys_
p-rx_bd[0]);
sdma_reg_write(lp, RX_TAILDESC_PTR, (unsigned int)cdmac_rx_bd_phys_
p-rx_bd[RX_BD_NUM - 1]);
if ((err = register_netdev(dev))) {
free_netdev(dev);
dev = NULL;
} else {
xps_ll_temacs[index] = dev;
}
return 0;
}
static void xps_ll_temac_free_one(int index)
{
unregister_netdev(xps_ll_temacs[index]);
free_netdev(xps_ll_temacs[index]);
}
static int __init xps_ll_temac_init_module(void)
{
int err = 0;
xps_ll_temacs = kmalloc(sizeof(void *), GFP_KERNEL);
if (!xps_ll_temacs) return -ENOMEM;
spin_lock_init(dev_lock);
spin_lock_init(rcv_lock);
spin_lock_init(xmt_lock);
if((err = xps_ll_temac_init_one(0))) xps_ll_temac_free_one(0);
return err;
}
static void __exit xps_ll_temac_cleanup_module(void)
{
xps_ll_temac_free_one(0);
kfree(xps_ll_temacs);
}
module_init(xps_ll_temac_init_module);
module_exit(xps_ll_temac_cleanup_module);
MODULE_LICENSE(GPL);
Thanks,
I have alot of work to do on our stuff, I might as well see if I
can
move to the powerpc tree at the same time.
BTW is there even the beginings of a non-xilinx lltemac driver out
there ? There were hints on the list, but I have not seen anything.
I would be happy to help advance the ball on anything anyone has
started.
Grant Likely wrote:
On Sun, Apr 20, 2008 at 2:31 PM, David H. Lynch Jr. [EMAIL PROTECTED]
wrote:
Thanks.
I am running linus's 2.6.25-rc9, but I can pull the Xilinx tree
or
yours - when your server is up.
I can not find any Xilinx powerpc configs in arch/powerpc/
config
Do I just need to do a
make ARCH=powerpc menuconfig and create one from scratch ?
That's right; I haven't merged any defconfigs. Roll your own.
Is simpleboot in your tree or the xilinx tree, if can not find
it
in Linus's ?
If you want to use the simpleboot wrapper; then you'll need to
pull
paulus' tree (Linus hasn't yet pulled his tree; but he probably will
any moment now).
Cheers,
g.
--
Dave LynchDLA Systems
Software Development: Embedded Linux
717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies
too numerous to list.
Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction.
Albert Einstein
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
※ ４月から所属・部署が変更になりました
--
柏木良夫
株式会社日新システムズ 東日本営業部
本 社 〒600-8482 京都市下京区堀川通四条下ル東側 堀川四条ビル
TEL 075-344-7977 FAX 075-344-7887
東京事務所 〒101-0024 東京都千代田区神田和泉町1番地 神田和泉町ビル
TEL 03-5825-2081 FAX 03-5821-1259
E-Mail [EMAIL PROTECTED] HTTP http://www.co-nss.co.jp/
--
--
Dave Lynch DLA Systems
Software Development:Embedded Linux
717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net
fax: 1.253.369.9244Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.
Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction.
Albert Einstein
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Compiling applications using cross compiler packs libc
Alessandro Rubini wrote: the glibc is also packed up as a part of application though I never make any calls to the glibc libraries. If however you really want to build an application without library, you should change the linker script. some or all of the following gcc flags might be useful if you are truly compiling an OS independent very small application -U__linux__ -nostdlib -nostdinc -mno-eabi -fno-builtin -nostartfiles -nodefaultlibs -nostdlib Also as Alessandro pointed out you will likely need a link script. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: HAVE_CONFIG
Arnd Bergmann wrote: On Tuesday 29 April 2008, David H. Lynch Jr. wrote: Why does CONFIG_PPC set CONFIG_HAVE_IDE ? Because it's possible to build ide drivers on the powerpc architecture. It means you get the option to enable to disable the old ATA (IDE) drivers. Arnd So CONFIG_HAVE_IDE means the architecture could have IDE rather than it does have IDE ? My BSP can't have IDE, does that mean I should add default n if MYBSP ? or somehow deselect HAVE_IDE in the config option for my BSP ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
HAVE_CONFIG
Why does CONFIG_PPC set CONFIG_HAVE_IDE ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
ARCH=ppc strncmp undefined
After pulling and rebasing to 2.6.25, I get strncmp is undefined when I try to link the kernel. I have not chased this down as just added strncmp into arch/ppc/lib/string.S But I would guess this is a side effect of changes to accomidate migration to ARCH=powerpc. There appear to be a number of remaining arch/ppc BSP's that need strncmp and therefore will not build in 2.6.25. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
simpleboot
I am trying to decipher hot to use the simpleboot devicetree wrapper and I am not grasping the process. I need an initramfs kernel, inside an elf wrapper. right now I get that pretty much for free. How do ask for a simpleboot wrapper kernel ? It is a target for a makefile in arch/powerpc/boot how to I cause that target to get invoked How does it choose the device tree to wrap ? How does it interact with things like initramfs ? -- Dave Lynch Pico Computing, Inc. Software Development Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.picocomputing.com fax: 1.253.369.9244 Cell: 1.717.587.7774 Tiny Mighty Machines ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: simpleboot
Grant Likely wrote: make simpleImage.boardname - or - make simpleImage.initrd.boardname The makefile will use arch/powerpc/boot/dts/boardname.dts for the device tree. Thanks, I suspected most of that. But I have not see simpleboot in Linus's tree yet, so I have to back port the patch from the paulus tree and that makes it harder to just try it. I am correct in assuming that if I have my .config otherwise properly setup for initramfs that it is going to merge the kernel, dts, and initramfs into a single image ? and is initramfs the plain or initrd target the correct one for initramfs ? -- Dave Lynch Pico Computing, Inc. Software Development Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.picocomputing.com fax: 1.253.369.9244 Cell: 1.717.587.7774 Tiny Mighty Machines ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx PowerPC
I would be ecstatic to look at/collaborate on what you have. I do not care if you clean it up. It can not be harder to work with than my own code or the Xilinx code. In the end I need Linux, GreenHills, as well as a lightweight stripped driver for a monitor and embedded mini-web server. I have all the above for the older PLB TEMAC in FIFO mode, but we are moving to the LL TEMAC. I started through the xilinx code and rapidly remembered how long it took to demacrofy the xilinx PLB TEMAC code down to a single source file with only the code actually needed, and got depressed. This is critical to us now, so I can put time into it. If I can figure out how to bring up a git server on my hosting service I am willing to host work on this - though one of the existing trees might be a better choice. Koss, Mike (Mission Systems) wrote: I have the start of a lltemac based on the new XPS_LL_TEMAC from EDK 9.2. I'm currently in the process of upgrading my design to 9.2. So I will be very much interested in the driver working ;). I'll see what I can get cleaned up and posted somewhere, if you'd like to take a look at it. -- Mike (sorry for the double post, if it happens but it seems that my last e-mail was blank per my records.) -Original Message- From: David H. Lynch Jr. [mailto:[EMAIL PROTECTED] Sent: Sunday, April 20, 2008 7:49 PM To: Grant Likely Cc: linuxppc-embedded Subject: Re: Xilinx PowerPC Thanks, I have alot of work to do on our stuff, I might as well see if I can move to the powerpc tree at the same time. BTW is there even the beginings of a non-xilinx lltemac driver out there ? There were hints on the list, but I have not seen anything. I would be happy to help advance the ball on anything anyone has started. Grant Likely wrote: On Sun, Apr 20, 2008 at 2:31 PM, David H. Lynch Jr. [EMAIL PROTECTED] wrote: Thanks. I am running linus's 2.6.25-rc9, but I can pull the Xilinx tree or yours - when your server is up. I can not find any Xilinx powerpc configs in arch/powerpc/config Do I just need to do a make ARCH=powerpc menuconfig and create one from scratch ? That's right; I haven't merged any defconfigs. Roll your own. Is simpleboot in your tree or the xilinx tree, if can not find it in Linus's ? If you want to use the simpleboot wrapper; then you'll need to pull paulus' tree (Linus hasn't yet pulled his tree; but he probably will any moment now). Cheers, g. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx PowerPC
Thanks alot. On quick review this looks great. I will see if I can get it working for me this weekend. Yoshio Kashiwagi wrote: Hi, I am writing the Non-Xilinx XPS_LL_TEMAC driver. Checksum offloading is incomplete although NAPI and KGDBOE are supported. Basic operation is working on EDK9.2 and EDK10.1. Furthermore, although the simple Non-Interrupt version for u-boot is also written, it is not known where I should post. Best Regards, Yoshio Kashiwagi - Nissin Systems -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: simpleboot
Grant Likely wrote: Its whatever kind of image you pass it. The simpleboot stuff must have hit Linux's tree today. I synced with it. created an arch/powerpc/boot/dts/pico_e1x.dts that is probably fouled up - but that is a problem for later. did: make -f Makefile ARCH=powerpc CROSS_COMPILE=powerpc-linux-uclibc- simpleImage.pico_e1x had to deal with a few different config options and then got: make[1]: Entering directory `/usr/src/linux-2.6.pico' make[1]: *** No rule to make target `simpleImage.pico_e1x'. Stop. make[1]: Leaving directory `/usr/src/linux-2.6.pico' make: *** [release] Error 2 So how does the top level Makefile know about the simpeImage.% target in arch/powerpc/boot ? -- Dave Lynch Pico Computing, Inc. Software Development Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.picocomputing.com fax: 1.253.369.9244 Cell: 1.717.587.7774 Tiny Mighty Machines ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: simpleboot
Josh Boyer wrote: simpleboot is in Linus' tree now. It went in with the first pull request paulus sent for .26. I got it, now to figure it out. I don't understand that comment anyway though. If you're working with a PowerPC board, why aren't you using the powerpc tree (paulus') to begin with? Backporting pieces of it to some other tree seems to be a waste of time to me... I am updating a port I did in 2005 ? based on the ml403 port that was in at that time. But it is an independent BSP. I need to move it to the current powerpc/devicetree, but I have to do so without breaking alot of things we have have working for years. At the moment I am somewhat surely about a number of the issues related to the powerpc/devicetree migration. Aside from the BSP issues, this breaks my boot monitor, and is going to require adding alot more code than I can either justify or see as necescary because there are some aspects of how the devicetree/powerpc stuff is architected that politely I think are brain dead. But I will get over it - probably. There just may be a bit of cursing and foul language before things work. -- Dave Lynch Pico Computing, Inc. Software Development Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.picocomputing.com fax: 1.253.369.9244 Cell: 1.717.587.7774 Tiny Mighty Machines ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx PowerPC
Thanks, I have alot of work to do on our stuff, I might as well see if I can move to the powerpc tree at the same time. BTW is there even the beginings of a non-xilinx lltemac driver out there ? There were hints on the list, but I have not seen anything. I would be happy to help advance the ball on anything anyone has started. Grant Likely wrote: On Sun, Apr 20, 2008 at 2:31 PM, David H. Lynch Jr. [EMAIL PROTECTED] wrote: Thanks. I am running linus's 2.6.25-rc9, but I can pull the Xilinx tree or yours - when your server is up. I can not find any Xilinx powerpc configs in arch/powerpc/config Do I just need to do a make ARCH=powerpc menuconfig and create one from scratch ? That's right; I haven't merged any defconfigs. Roll your own. Is simpleboot in your tree or the xilinx tree, if can not find it in Linus's ? If you want to use the simpleboot wrapper; then you'll need to pull paulus' tree (Linus hasn't yet pulled his tree; but he probably will any moment now). Cheers, g. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: interrupt handlers PowerPC via GCC
Tehn Yit Chin wrote: Hey Scott, Thanks for the reply, I shall investigate further. I wasn't talking about interrupt handlers in Linux as such, but using powerpc-eabi-gcc to write an ISR for the MPC5516. (I guess that could be off-topic on this mailing list, but I thought the folks on this mailing list would probably know the answer pretty easily). I was hoping that gcc would generate the prologue and epilogue code for me via the interrupt attributes. I know nothing about GCC's interrupt attributes, however, there is no problem writing ISR's from scratch (no OS) for the ppc. There are several boot loaders, monitors etc. out there with examples. There is even one inside the Linux Kernel source - though it i probably far more complex than you need. Somewhere I have something for the ppc405 I can send you - but most ppc's are similar. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ML403 Linux port questions
I have a two part series that should be appearing in Circuit Cellar either this month or next, that is targeted very close to what you are looking for. You have to be a masochist to try to build linux kernels under cygwin. It is purportedly doable - I have never succeeded, but very painful. If you must work under windows - I know alot of engineers do, then I would highly recommend colinux. www.colinux.org. It will give you linux and windows running concurrently on the same machine with very little pain, no additional cost, there is a small amount of grief getting windows-colinux networking functioning, that is not critical but it is nice. Getting X windows running is substantially more effort and is very nice - but completely unnecescary. Colinux is a much easier and lighter weight solution than virtualization. That said I would highly recommend you seriously consider doing linux development without windows. The targets you are going to be developing for are going to run linux. The initial learning curve might be steeper, but the payoff is greater. Everything you learn on the development side will apply to the target. There are bazillions of Live CD's you can try. I would highly recommend Ubuntu. Its alot like windows - except mostly friendlier and it works. Personally, I went the roll your own method for creating a development environment. I have no experience with ELDK. Buildroot and many other environments dictate a very specific way of working. They guide you to a working solution faster but I find myself fighting against their limitations all too soon. Unfortunately crosstools has not been updated in a while, and does not officially support uClibc (it does support glibc). uClibc is very appealing for limited resource systems. There is a crosstools-ng project, but it does not have ppc support. It would be really really nice (hint) if Xilinx would get their microblaze compiler code into the gcc distribution. Phil Hochstetler wrote: I'm setting up a new development environment to get a working port of Linux on the Xilinx Virtex-4 chip (I have a Xilinx ML403 board). I'm looking for the quickest way to get a working development environment for the 2.6 kernel without paying thousands of $$ (what happened to MontaVista?). My first attempt was to use google and found lots of resources. The problem is that much of the info is dated or makes assumptions about your environment. I read Grants write-up at http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex. Because I want to use Windows XP SP2 as the host if possible, I went down the path of installing the current Cygwin and was able to create cross tools (gcc 4.1) successfully. The problem I am having is that the Linux build process requires a newer gcc than 3.4.4-3 which is what Cygwin provides. I have used the EDK to build a bsp package successfully so that is not a problem. I tried to compile the 2.6.24.2 mainline kernel but it fails to compile using the Cygwin tools (it never gets as far as using them). I guess what I am looking for is advise on the lowest risk, easiest to set up environment to setup that will just work. Also advise on which kernel to use. I don't need a detailed tutorial but a high level direct that is known to work. I am thinking of using either the secret lab tree or the Xilinx tree as recommended in Grants wiki page. Should I just forget using XP and install a Linux (x86 processor so I must use cross tools)? If so, what is the recommend distro and what version? Thanks for all your sharing of experience. I hope to contribute back as soon as I can. --phil ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ML403 Linux port questions
Grant Likely wrote: On Fri, Feb 29, 2008 at 10:24 AM, Phil Hochstetler [EMAIL PROTECTED] wrote: I guess what I am looking for is advise on the lowest risk, easiest to set up environment to setup that will just work. Also advise on which kernel to use. I don't need a detailed tutorial but a high level direct that is known to work. I am thinking of using either the secret lab tree or the Xilinx tree as recommended in Grants wiki page. Should I just forget using XP and install a Linux (x86 processor so I must use cross tools)? If so, what is the recommend distro and what version? Yes, absolutely. Going down the cygwin path is doable, but it is a path of pain. I strongly recommend using a Linux host. (I personally use Ubuntu, but you should have good success with any disto. Use what you're most comfortable with). The simplest approach to get running with a Linux box is to install either VirtualBox or VMware and create yourself a Linux virtual machine. That will get you up and running without having to obtain new hardware or risk breaking your XP setup. Mostly I would agree - however, I would suggest something like colinux rather than virtualbox or vmware - If you must do development work on a windows system. Colinux is fairly trivial to get up and running. It gives you real linux running as a process under windows. There is no virtualization going on at all. The only caveat is that all access to host hardware must go through windows. This is much less of a big deal than it sounds - if you are talking about a development environment. It is also useful because from colinux running under windows you can have access to your windows filesystem. This means that you can use REAL linux tool fairly transparently on windows while still running windows. I rarely run windows anymore. But when I do I run colinux, and I write linux shell scripts that run under colinux to preform tasks I find difficult to do under windows. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
USB 2.0 Highspeed host with Xilinx/linux ?
Anyone have any experience/recommendations for doing USB 2.0 Highspeed hosts with Linux driver support, in a Xilinx environment ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Xilinx PowerPC
So when you have Xilinx under powerpc working, do we pull it from your git tree or the xilinx one ? Will there be an announcement ? How about a one paragraph getting started guide to moving a xilinx ppc bsp to xilinx powerpc. Like ? step 1). Generate a dts - gen-mhs-devicetree ? And pass it to through your boot loader to Linux ? Step 2). the code in arch/powerpc/ is the devicetree equvalent to arch/ppc/platforms/4xx/xilinx_ml410.c Step 3). device drivers need to change initialization/setup from to ??? Just something to give those of us with no clue, a small one to start. Thanks. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Block devices
Sometime recently it seems to have become possible to disable the whole block device subsystem. Though in my tests I can't quit build with it disabled. Anyway, for an embedded device this might be appealing. how does this interact with initramfs and flash ? Can I boot an initramfs kernel without a block device ? Can I write a filesystem driver for a flash device that does not require a block device ? Are their any examples of something even close ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kernel symbol version history
Thank you. I made use of one of the linux cross reference sites. Though unless I don't know how to effectively use them trying to track the history of a function, typdef, define, .. is not particularly easy using lxr. Grant's sugestion with git was closer to what I was looking for - except that in some instances needed to go back farther than it would take me.. Jean-Christophe Dubois wrote: Hi David, You could try the various linux cross reference web site out there. It is not necessarily complete (some linux version might be missing) but it can be usefull to lookup if some symbols/define/typedef were available in a particular Linux version. Have a look there. http://free-electrons.com/community/kernel/lxr Regards JC On Wednesday 05 December 2007 17:17:25 David H. Lynch Jr. wrote: This might be slightly OT here, but would anyone know where there might be a reference that indicates at precisely what version a given symbol either appeared or disappeared within the Linux kernel ? As an example if a driver is supposed to work for 2.6 and 2.4 and uses sysfs, or cdev, or alloc_chr_dev_region or ... How can one tell at what point that api or symbol appeared so that the proper conditionals appear within the driver. The last one that bit me was I made a collection of casting changes to address 64bit vs. 32bit targets, and found that using the C99 fixed size types - uint32_t, ... made life much more pleasant, after putting them I nobody else could build because uintptr_t did not appear until 2.6.24, and I still have not figured out exactly when uint32_t etc. appeared. I would think there ought to be some resource besides group memory to look this up ? Is there a way to use git to look back through the history of a symbol rather than a file. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Kernel symbol version history
This might be slightly OT here, but would anyone know where there might be a reference that indicates at precisely what version a given symbol either appeared or disappeared within the Linux kernel ? As an example if a driver is supposed to work for 2.6 and 2.4 and uses sysfs, or cdev, or alloc_chr_dev_region or ... How can one tell at what point that api or symbol appeared so that the proper conditionals appear within the driver. The last one that bit me was I made a collection of casting changes to address 64bit vs. 32bit targets, and found that using the C99 fixed size types - uint32_t, ... made life much more pleasant, after putting them I nobody else could build because uintptr_t did not appear until 2.6.24, and I still have not figured out exactly when uint32_t etc. appeared. I would think there ought to be some resource besides group memory to look this up ? Is there a way to use git to look back through the history of a symbol rather than a file. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Init hangs on Xilinx4
schardt wrote: Hi David, thanks for your help. I am presuming you are using PK's UartLite driver. I use the Kernel from Grant's git server, and let me look... yes its from Peter Korsgaard :) Try printing out membase some time possibly in ulite_console_setup. If the value of membase is 0x40600 that is your problem. It should be something like 0xfd I think. Mmmh, my EDK Project maps the uartlite to 0x4060, so i think its okay. but i can try it at a higher adress it is very strange. i use the same hardware setup and boot from system-ace without any problems. Another posibility that I thought of since you are using Peter K's driver. If you have any interrupt problems I think you could get your current behavior. During boot console I/O is not interrupt driven. When the OS sends a string the whole string gets sent and then the console write exits, but very close to running init, the console switches to using the full driver. PK's driver is interrupt driven. If the UartLite TX FIFO empty interrupt is broke in anyway, it will send until the first time the FIFO fills and then stop. The interrupt could be broken in firmware - not properly connected to the PIC, or it could be broken in software - however your driver is receiving its interrupt configuration, the driver may be receiving the incorrect intterrupt #. At one point I tried to add timer driven polling to PK's driver similar to that in the 8250 and others - we have clients that run without any PIC, but trying to figure out what was going on proved sufficiently difficult I just went back to my own driver. Regards Georg --- --- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt --- --- -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
John Williams wrote: I'm not sure I agree, here, given that most people building MicroBlaze systems are doing so with uClinux-dist (or PetaLinux), you can do a full rebuilt, kernel libs apps, in a couple of minutes. Much shorter than sythnesis and PR, that's for sure (and runtime is linear in size, unlike PR :) I am mostly a lurker in this debate. Pico has V5 cards that we intend to run MicroBlaze Linux on, but as I would end up with the Linux work and I have spent most of the past 6 months getting our host software working under Linux, OpenBSd, and OS X, the time to play with the MicroBlaze just was not there - but might be soon. I did take note that Xilinx purportedly has an MMU for the MB now. This is particularly intriguing. To cast in my .02 - Pico is likely to either not run the MB on our V5's or run a fairly bloated one. uClinux only interests us - because the MB would not run full blown Linux. Given the possibility that it might, we become less and less interested, in the smallest MB posible. I know this contradicts many things I have said about our position on Our PPC Linux, but our clients who want Linux really want the whole thing. At this moment I do not have a full appreciation of all the MB instruction options and emulating them through exception handlers. But my guess is that we would turn everything on that has any significant impact on linux kernel performance. I am glad that John mentioned MB/PPC convergence. Particularly with an MMU it is our hope that our PPC BSP for our V4FX boards ddifferes as little as possible from our MB BSP for V4/V5 LX boards. I am not looking to tell someone else how to spend their time - but Pico would have little interest in dynamically mangling a kernel to adapt to different CPU parameters. It sounds like alot of work, and alot of grief. We would design our own CPU first. My experience tells me that if the microblaze can be configured in a particular way, *someone* will want to do it (and still boot linux on it!) We still have people building MicroBlaze 3.00 in Spartan2E, with EDK 6.3. And autoconfig works! Exceptions on/off, MMU on/off (runtime configurable on that?). I would still venture that with very few exception people are going to gravitate to the extremes, mostly all off, and mostly all on. Mostly on would probably run full blown MMU Linux, and mostly off would either run uClinux or nothing at all. Frankly I am not sure that with everything mostly off, you wouldn't just pick a much smaller less powerful core - something 8 or 16 bit that is a fraction of the size, then the CPU become a logic element, rather than something to run an OS - I.E. I can build a graphics processor in an FPGA implimenting most things in hardware, but ploping a cheap (small) CPU in to do general purpose low performance administrative tasks, that might take more space in hardware. Other things that would be higher on my hitlist would be seeing the GCC MicroBlaze CPU support find its way into distribution GCC's. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Init hangs on Xilinx4
I had a similar problem. In my instance it turned out that I was inadvertently using the physical address of my uart as the output address. This worked during boot becasue there was a 1:1 physical-logical entry stuffed into the MMU. But since Linux did nto know about it, as soon as the VM system decided to use that TLB entry IO died - right in the middle of a string. While it is unlikely you made exactly the same mistake. One area you can check is memory. What is your output device ? schardt wrote: Hi all, i still have some problems booting linux from flash and don't know how to debug. i have a xilinx4-ppc with 64MB Ram and 4MB Flash, U-Boot works fine, kernel is booting, but my little hello world program runs as init, died after printing He (intead of Hello World). i tried initramfs with build in cpio-image and jffs2 rootfs Is there a log-buffer to look at ? Should i try another compiler version ? (btw. booting from systemace works with the version i use). --- famous last words : [ 50.476641] VFS: Mounted root (jffs2 filesystem). [ 50.533581] Freeing unused kernel memory: 68k init He --- regards Georg --- --- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt --- --- ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: initramfs and busybox kernel oops
fabien wrote: hi all, I'm trying to get busybox working on my custom board mpc855t and linux kernel 2.6.19 (from eldk 4.1 uclibc). I've built an initramfs that i link directly in kernel. To verify whether the kernel is able to lauch the init process i've compiled a small hello world program. But no when i try with busybox 1.8.1 staticaly linked i got an Oops error kernel access to bad area. I don't know why the former work fine but no the latter. If someone have some ideas for where to look for ? In my initramfs there is : in /dev : crw-r--r-- 1 root root 5, 1 nov 22 13:32 console crw-rw-rw- 1 root root 1, 3 nov 26 10:10 null crw--- 1 root root 4, 1 nov 26 10:11 tty1 in /bin : lrwxrwxrwx 1 root root7 nov 26 10:17 ash - busybox* -rwxr-xr-x 1 root root 793804 nov 26 13:57 busybox* lrwxrwxrwx 1 root root7 nov 26 10:17 cat - busybox* (and others links) My init script file (/init) : #!/bin/sh /bin/ash It took me a while to get initramfs running. But after I did I have been very happy with it. It is possible you need more in /dev. My initramfs has much more than yours - though it is still quite small. I sort of stole it from somewhere. I think I took an initrd from somewhere expanded it an culled out what iI did not want. Busybox is still the bulk by volume, but that got me all the /dev /etc/ ... stuff I needed You can pull mine from http://www.picocomputing.net/files/initramfs/ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
Grant Likely wrote: On 11/26/07, Koss, Mike (Mission Systems) [EMAIL PROTECTED] wrote: DLAnd once again a plea to ALWAYS make version/capabilities registers DL atleast an optional part of every design. DLEmbeddeding a device tree into a design might be fairly expensive. a DL pair of read only 32 bit registers is damn near free - basically the DL FPGA equivalent of atmost 64 diodes or resistors. SN Actually, device trees actually seem to be cheaper (in the whole system sense) than such registers. Unless there is something I don't understand? First the decoding for the register is almost certainly already present for the other registers for the device. After that - assuming that an FPGA can impliment a read only register as easily as discrete logic - it should be damn near the most trivial peice of hardware imaginable. It is simpler than 64 bits of RAM. It can be simpler than 64bits of ROM. I do not think there is a way in the world that devicetrees can more cheaply provide the same information. They might me more flexible, or powerful, but 2 64bit read only registers. Anyway I am not arguing that you should not do devicetrees. Just that you should do version/capabilities registers - atleast as a IP option always. Every OS does nto support devicetree's. Every application of an FPGA not going to have that as an option. But every peice of software that can access and I/O device can access its version and capabilities registers. *If* edk is generating our device tree(s) for us, *then* version registers are not needed by Linux. I want both. I want version registers - because they are ALWAYS available. They are available to software running on the FPGA that has no clue what bit file it is running on,how it got to be running. Devicetrees may provide a great deal more information bit it is not hard to come up with scenarios where that information might not be present. It is like the security arguments about biometric identification. I can forget my key card, my password, ... But I am unlikely to forget my thumbprint or retina. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
Koss, Mike (Mission Systems) wrote: Time for my $.02, since I am heavily weighting my future designs on the use of the device trees. :) (and b/c I don't check my work e-mail from home ;P) From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED] Sent: Sunday, November 25, 2007 6:59 PM To: David H. Lynch Jr.; Grant Likely; linuxppc-embedded Subject: RE: Xilinx devicetrees SN the device tree is packaged (somehow, TBD) along with the bitstream. If xilinx wants to optionally incorporate the device tree into the bitstream in a fashion that can easily be worked out by software - that would be excellent. I don't know if packaging the device tree with the bitstream is the best way to go. It's possible that it could lead to headaches for certain systems that have security restrictions. Make it an option. Where are the systems with security restrictions going to get their hardware information ? Besides - though I am not aware off the top of my head of a bitstream decompliler, still if you have access to the bitstream you have access to the information about the device. We deal with alot of high security applications. Security restrictions have to make sense. blocking devicetrees for security reasons is like telling somebody they can have the manual in computer readable form, but not on paper. Further if you are going to boot an OS that requires devicetrees then the devicetree must be somewhere - whether it is appended to the bitstream, appended to the kernel, compiled into the kernel, in a separate file, it still has to be present. The same could be said for using it w/ the SystemACE to load it into RAM after the image. (which is what I'm currently doing for my 2 linux images in lieu of a true on-chip bootloader). I am already taking the security concerns into account for future revisions of the hardware wrt to using a SystemACE, and am planning on moving the device trees into NV storage like FLASH. I am not working with MLXXX boards. Pico has no System ACE. The card has an FPGA, flash, ram and a few other things all in a CF/Cardbus/expressbus formfactor. You program it in a host with our tools. You run it either in the host or standalone. SN I don't understand the 'burden on software developers'. The code to do this will just be standard code. I got 16K of RAM for my boot loader and that 16K has to do alot more than just manage device trees. I think we have 2K left. In that I have to fit scripting, and ethernet, so where am I supposed to fit the standard code ? If the devicetree is say at the end of the bit file I can probably copy it to ram and pass a pointer to linux in maybe a couple of hundred bytes. If I have to do much more it ain't happening. The worst that one can say is: SN 1) I need several KB additional non volatile storage. Given the size of the FPGA bitstream, this can't be a huge constraint. Several KB is NOT happening. The bitstream is in flash. Flash is not a limited reasorce for us. FPGA cells, and BRAM are precious as gold. The more we use the less our clients have. Different systems are going to have different resource constraints. What is unlimited for me may be severely limited for someone else. What is unlimted for you may be seriously limited for me. I do agree that using more FPGA resources is not a solution to the problem. I'm already hitting 80% usage on a FX60 and trying to squeeze more real estate for storage of the device tree seems silly. Especially since that would require that every image have this extra hardware built into it just to support booting a Linux kernel. Why should I have to have different hardware to boot linux, versus non-kernel, xilkernel, or other (GHS, LynxOS, etc..)? One of the problems is that neither devicetrees, nor any of the ways of tracking them are one size fits all solutions. I do GHS work, it would be nice if GHS supported devicetrees and maybe it will. bound to the kernel, in a separate file, appended to the bitstream and in the FPGA fabric all have pluses and minuses. One reason I am harping on version registers is they are extremely cost cheap, can easily be made optional, and can be fairly easily incorporated into any OS (or no OS - we do that too). They are not a replacement for devicetrees. But they still have very important uses in many environments. SN Certainly.. But in a sense, these are all intermediate files on the path to the image on the board. Unless we are going to teach linux to read and interpret .bit files while loading, then devicetrees are intermediate in an entirely different sense. The hardware works fine regardless of whether their is a devicetree. But Linux may not boot. My objective is to get alot of software - linux, GHS, and standalone apps, to all load - from a single executables, accross multiple different bit
Re: Xilinx devicetrees
Stephen Neuendorffer wrote: In any event, why do you do this rather than just run out of the flash (or a ram copy of the flash?) This is not literally true, but the parameters are nearly the same - pretend we are using NAND flash and storing executables as elf files. We can not run from flash because: The code has not been relocated the flash is not persistent We do load the flash/elf file into DRAM dealing with elf issues along the way and then execute it. We can do something similar for devicetrees, actually just passing Linux the offset from the begining of flash to the devicetree would be sufficient. Or if finding the devicetree inside the bitsstream can be accomplished fairly simply, just passing the offset of the bit file. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
First; I am not deliberately trying to be obstructive. It is apparent that the ppc kernel is moving towards devicetrees and initially I thought that sounded like a good idea. Now I am trying to reconcile the positive benefits with my perception of the negative side effects. Yes, you are correct in all of the above. One more point; it is also possible to bind the device tree up with the kernel so you've got a single image just like old times. :-) But that is not actually the same is dynamically detecting configuration. On an ordinary PC where the critical core configuration is somewhat fixed and the rest can be determined by firmware (code), this makes a great deal of sense. In a system where the hardware itself is actually firmware and there is little or no startup software to query the device and build a device tree dynamically for you, it is of more questionable value. Maybe if there is some mechanism existed to have the devicetree stored into the FPGA firmware where there is a natural link between the implimented hardware and its description. But I am not gathering things going in that direction and storing the device tree in the FPGA consumes valuable FPGA resources. The board description has to live *somewhere*. I have done alot of code for many purposes where the code went to a great deal of effort to figure out its own environment dynamically. Some (relatively minimal) assumptions have to be made. And some balance has to be struck between code complexity and dynamic flexibility. though sometimes dynamic detection can be simpler. Part of what bothers me about devicetrees, is that the entire design seems to presume either standard hardware with minimal permutations, or fairly complex firmware - like boot roms to dynamically build atleast parts of the device tree. That being said, using the device tree does not preclude using platform code to setup devices *where it makes sense to do so*. Many things are one-off board specific things that are not well described with the device tree. For example, we've been debating how to handle on board sound which use common codec chips, but have custom wireup. The codec chip can use a common driver, but the wireup is handled with an ALSA 'fabric' driver that is pretty much a one-off for the board. It probably makes more sense for the fabric driver to be instantiated by the platform code rather than trying to do a full device tree representation. So I can hard code some relatively simple stripped devicetree that may do little more than specify the CPU, major elements of the memory map (maybe), and say the PIC, and then let the BSP, detect things like the UART(s), NIC, ... In arch/powerpc we're *still* data driven; it's just that the data is no longer compiled into a static structure. Plus, in the transition we've moved from needed per-device platform data structures to a more expressive format. Also, per-board platform support code has become much simpler (compare ml300.c in arch/ppc with platforms/40x/virtex.c) I have not pulled your tree in a while - are devicetree's in your current git tree ? Thanks for the remarks. Again, I am just trying to figure out how to keep my Pico code in sync and hopefully make my life better rather than worse at the same time. Unfortunately, I am coming to the conclusion that DeviceTrees are probably not going to make it that much better, but they are probably not going to make it that much worse either. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
Stephen Neuendorffer wrote: -Original Message- From: [EMAIL PROTECTED] on behalf of Grant Likely Sent: Sat 11/24/2007 9:12 AM To: David H. Lynch Jr. Cc: linuxppc-embedded Subject: Re: Xilinx devicetrees On 11/24/07, David H. Lynch Jr. [EMAIL PROTECTED] wrote: I am having some difficulty grasping the significant advantages to this. If the firmware for a given target is not fairly static - and I load different firmware depending on what I am doing all the time, then I know have to manage both a bit file for the firmware, and a devicetree file describing it to the kernel. The device tree file is meta-information about your bitfile. Think of it as 'part of the firmware'. In the (hopefully short) future, it won't even have to be managed, it will just be one of the things that is generated by the EDK flow. Part of the bad news is that I have been kept so busy on the software side of things, I have had very very little time to play with xilinx tools and firmware. But overall at Pico we have a love hate relationship with them. Our products are primarily wrapped arround FPGA's particularly Xilinx. We love what we can do. But there are days that I here loud muttering about completely rewriting all the xilinx software tools - there is a surprisingly large amount that many of the Pico firmware people do not use already. Regardless, I think I saw a post of yours on the microblaze list about exporting a devicetree list with the firmware. that is probably a better solution that what exists now. You won't have to write a bunch of code that deciphers which fpga firmware you are running on.. That information will be found with the firmware and can be dealt with in a generic way. If you already HAVE that code, you can keep using it, but maintaining that kind of code is probably not where you want to spend your time. I am curious - with the firmware is not the same as in the firmware. But since you brought up deciphering firmware - to me and to Pico, and I gather to alot of others, providing indentity information within the firmware is a really really important issue - one which xilinx seems to be unable to make up its mind about. There are frequent posts addressing issues like this driver only works with this version of some IP - but there is no way to query the IP to enough detail to determine whether the driver will work. It is one thing to make version registers an option. It is entirely different to just omit them entirely or change the IP without changing the version. Our clients beat us up for things like that. DevieTrees do nto solve that problem. Anyway, my .02 would be to put the device tree into the firmware. In a perfect world - litterally in the firmware so that when the firmware loads the device tree data is already in the FPGA somewhere that it can be easily ready - oh and do that without consuming many FPGA resources. But in a more likely realworld scenario - append the information to the .bit file in some fashion so that if can easily be found and passed on. Binding it to a kernel, is a non-starter for us. That means a permuation of multiple different OS kernels for each bit file we might have. That is huge number. I am tasked with getting one binary for each OS to work with nearly every device(hardware) we make including addressing options that change with firmware AND the whim of the user. But life might not be to unpleasant - it might even actually be better, if our kernel loader just extracted the devicetree from the end of the currently executing firmware. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
SPI, I2C
I have been asked to do SPI and I2C drivers for Pico cards. I am trying to grasp what the practical use of either could be in an environment where neither SPI nor I2C are going to be able to communicate outside the FPGA. I am guessing that SPI and I2C implementations already exist for Xilinx FPGA's - any chance that drivers might already exist ? I would prefer not to charge a client to reinvent something that exists, or that can not serve a useful purpose. I am not trying to imply that SPI or I2C are not useful, just that they are communications channels, and unless they have outside I2C or SPI hardware to talk to what purpose might they serve ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
Grant Likely wrote: nope, not at all the same as dynamic detection; just backwards compatibility with the way we do it now for arch/ppc. Other things being equal a common architecture is preferable to a collection of independent ones. No, it doesn't make sense to store is in the FPGA fabric; but if the design already contains BRAM then it could be placed there and reclaimed for other purposes after booting. Or anywhere in RAM for that matter. I don't know how feasible is to load a device tree into SDRAM at FPGA config time. I am not expert on this, but at Pico we already store our boot monitor in the .bit files in BRAM. But that is not free. It is one of the reasons we do not use u-boot. Our boot monitor must fit into 16K of BRAM. Must be able to perform selftests on critical hardware, support a flash file system, load bit files from flash to the FGA, load and exectute elf files, allow a small set of user commands, and handle hosted vs. standalone operation. And aparently extract the devicetree from a bit file and pass it to a linux kernel. Ah; I think I see the disconnect we're having. Device trees are not about, *and never have been about*, device detection. The device tree is simply the communication medium used to describe the hardware. It doesn't matter if you choose to use a 100% dynamically generated device tree from intelligent firmware or a 100% static device tree blob. All that matters is that the kernel is able to trust the information handed to it by firmware. Device detection is not a problem that the device tree is designed to solve. It is designed to solve the problem of telling the kernel what the platform looks like (which occurs after the detection stage). In static or fairly static hardware, that's fine. Even in somewhat dynamic hardware with large quantities of startup resources - like a PC. But in highly dynamic hardware with fairly limited resources it starts to become an issue. Still if xilinx intends to generate the device tree with the bit file - even better appended to the bit file or embedded in the FPGA if feasible, this could still work. I do not see Detection as independent of communication. Aside from a very minimal core, If device drivers can do a good job of validating their hardware (back to my version registers issue in another post) and I just load them willy nilly and let the ones that have no hardware fail (Gross over simplification, but still viable) then a communication scheme is meaningless. Going the opposite direction, if I do not have the resources to detect the hardware and build the devicetree dynamically, AND I have highly dynamic hardware, AND I do not have an easy method I can trust of aquiring another source for the hardware description, devicetree's aren't any help. There are alot of AND's there but most if not all appear to be present with FPGA based systems. arch/powerpc support for Virtex is now in Linus' mainline tree which will become 2.6.24 Guess it is time to pull Linus again. No, unfortunately they don't deal with the problem you're facing (which I'm facing also). But it will be solved if we figure out a sane way to bind the device tree up with the FPGA bitstream without consuming FPGA resources. Note to Xilinx: There MUST be some way of binding a device description to a bit file. neither building it into the FPGA fabric nor appending it to the end of the bit file are perfect solutions, The former is more powerfull and flexible but wastes precious resources. The later is more complex and puts more burdens on software developers, and may be completely unfeasible in some environments - not mine fortunately. Regardless, something must be done. An odd collection of devicetree files co-mingled with a collection of bit files, is little better than xparameter files all over the place. And once again a plea to ALWAYS make version/capabilities registers atleast an optional part of every design. Embeddeding a device tree into a design might be fairly expensive. a pair of read only 32 bit registers is damn near free - basically the FPGA equivalent of atmost 64 diodes or resistors. Cheers, g. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Xilinx devicetrees
I am following developments regarding device trees for xilinx boards both here and on the microblaze list. I am trying to get a grasp on what they will really do for me and what using them will demand. Please correct any misperceptions: As I understand it devicetrees are basically just a tree structured binary database describing the hardware. They have some heritage in OpenFirmware. There are tools to convert some human readable representations into the binary form. There appear to be tools to take xilinx firmware projects and create a devicetree database from it A BSP using devicetree's configures its hardware, drivers etc, by querying the devicetree database. It it possible to pass the device tree database independent of the kernel itself some what similar to the way many bootloaders pass initrd filesystems. So in the end I write a BSP that could support a wide variety of hardware and compile a single kernel that could be passed different devicetree databases representing different xilinx firmware, and still hope to work. But in return for making the BSP more generic (sort of), I now have to somehow get the correct devicetree database passed for each different firmware set that I load. I am having some difficulty grasping the significant advantages to this. If the firmware for a given target is not fairly static - and I load different firmware depending on what I am doing all the time, then I know have to manage both a bit file for the firmware, and a devicetree file describing it to the kernel. Currently for base hardware we maintain as much design consistancy as possible accross all our different cards/firmware. particular hardware/firmware blocks/IP's may or may not be present - but if present they are always the same - the Same Uartlite at the same location, on the same irq, same for PIC's, TEMAC's ... For the most part it makes the most sense for us to use code to detect the presence/absence of specific baseline hardware and then to load non-base custom drivers after boot. What am missing about devicetrees that would make me more interested in them ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Initramfs problem on virtex4fx
schardt wrote: Hi all, i try to run linux from flash with the initramfs as root filesystem. i wrote a simple hello_world as init to test the initramfs. the kernel boots normaly, but instead of the complete Hello World i see only He and the system hangs. Does anyone have similar problems ? And solved it ? ;) Regards Georg The Pico Linux BSP uses initramfs. The whole Pico Linux development environment including busybox and an initramfs cross compilers, Linux source - pretty much everything you need is at http://www.picocomputing.com/downloads/software.php, everything is incorporated into a Colinux install, though you can just pull out the necescary peices - the cross compiler, busy box, intramfs and linux source if you are working completely under linux. --- --- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt --- --- ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Xilinx TEMAC driver
John Williams wrote: Hi David, GRant Any progress on the ll_temac driver since July? In EDK9.2, ll_temac is really the only supported ethernet solution, apart from ethernet lite (yuck). If there's a PPC version in a reasonable state, i'm happy to see what's requierd to port it across to MicroBlaze. Little has been done since July. The version I posted did have ll_temac support that once upon a time worked. I have little experience on the firmware side - yet. Though I keep getting pushed towards it, I also end up sufficiently busy on the software side as to have no time to even finish installing Xilinx tools. But I am pretty sure Pico is using 9.2 and I am completely certain we are not currently using the ll_temac. BUT, there is serious discussion about going back to it. We strive for the absolute smallest firmware needed for a task. We have clients that need Linux or GreenHills on the card AND are designing large blocks of firmware for their own purposes. No matter how much free space we give them they need more. I have heard that the current incarnations of the ll_temac support interrupts. This was the deal breaker for us on the original ll_temac. Linux could be made to work (fairly badly) without interrupts, but while nothing is impossible, trying to write a GreenHills NIC driver that is polled was an excercise in futility. I managed to get a polled serial driver working - but it was very ugly. Presuming that the currently ll_temac is smaller than the plb implimentation and presuming that it has the option of interrupts, it is likely to return to my todo list shortly - of course that list is fairly long. I have spent the past several months massaging Pico's Host utilites to run under Linxu 2.6, 2.4, OpenBSD, and Mac OS X. I have been living exclusively in Linux since March. I accidentally obliterated my Windows partition and the recovery partition installing OS X86 and have not even noticed it is gone. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: writing to flash from linux
Yoni Levin wrote: Hi , I have EN29LV640H flash (http://www.eonsdi.com/pdf/EN29LV640.pdf) On my mpc83xx board. How can I write data to flash from linux.? I guess it done with mtd , there is an example somewhere? Thanks. I know nothing specific about your board or flash, but MTD is the proper system for handling flash. You need an mtd driver for your board - it is possible something already exists, but if not you need to write it. That driver may be extremely simple - if your boards flash system if not very complex. Some of the issues are ? Is your flash partitioned - are there multiple regaions of flash that each serve different purposes - such as a boot loader, a kernel, an initrd and separately a file system - or even more than one file system. Is your flash chip recognized by Linux (likely) Are there special conditions for reading/writing flash on your board - i.e. do you have to enable special voltages or protection bits - board specific protection not chips specific, Does your board window the flash such that only part of it is in the CPU's memory space at one time. Does your board have some odd quicks for accessing flash - like requiring a 32 bit read to get a 16bit value ? All of these are handled by the mtd driver If as an example you have a very standard CFI flash chip, that has no windowing, no special read/write enables, is always fully in the CPU memory space at the same place, and all the flash is going to be used for a single filesystem with no reserved blocks, bootloaders etc. The mtd driver could be trivial, there might even be something that can just be used as is. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Consolidate XILINX_VIRTEX board support
Josh Boyer wrote: arch/boot/simple/embed_config.c jusst seems to be a random collection of board specific code anyway. A giant case statement implimented with #ifdef's. It is just screaming to be done some better way. You mean like a device tree? ;) josh Maybe, I am waiting to see somebody move something to device tree so that I can get a better grasp of what it is and how it works. From what little I know I think it is going to be very significant for my BSP - we are trying to use a single binary for alot of different boards, or the same board with different firmware. From what I am gathering I can have the loader pass a device tree to the kernel and the device tree will basically describe the hardware to the kernel. Only at the moment I don't have the time to learn enough to attempt to lead the charge moving xilinx stuff to powerpc. Is there a way to do this in small peices ? It would be nice to end some of the debate on how to setup ppc/4xx for multiple xilinx targets and just get it over with and move to powerpc device tree, ... But I can't beat others up for what I can't find time for myself. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Consolidate XILINX_VIRTEX board support
arch/boot/simple/embed_config.c jusst seems to be a random collection of board specific code anyway. A giant case statement implimented with #ifdef's. It is just screaming to be done some better way. Peter Korsgaard wrote: WR == Wolfgang Reissnegger [EMAIL PROTECTED] writes: Hi, WR diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile WR index 5b87779..05631fe 100644 WR --- a/arch/ppc/boot/simple/Makefile WR +++ b/arch/ppc/boot/simple/Makefile WR @@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6) += embed_config.o WR boot-$(CONFIG_8xx) += embed_config.o WR boot-$(CONFIG_8260) += embed_config.o WR boot-$(CONFIG_EP405) += embed_config.o WR -boot-$(CONFIG_XILINX_ML300) += embed_config.o WR -boot-$(CONFIG_XILINX_ML403) += embed_config.o WR +boot-$(CONFIG_XILINX_VIRTEX) += embed_config.o Don't do that. Other boards with Xilinx FPGAs don't necessarily need embed_config.c WR boot-$(CONFIG_BSEIP) += iic.o WR boot-$(CONFIG_MBX) += iic.o pci.o qspan_pci.o WR boot-$(CONFIG_MV64X60) += misc-mv64x60.o WR diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c WR index 840bff2..e0b8954 100644 WR --- a/arch/ppc/boot/simple/embed_config.c WR +++ b/arch/ppc/boot/simple/embed_config.c WR @@ -744,7 +744,7 @@ embed_config(bd_t **bdp) WR } WR #endif /* WILLOW */ WR -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403) WR +#if defined(CONFIG_XILINX_VIRTEX) WR void WR embed_config(bd_t ** bdp) .. And if they do, they might have another embed_config (E.G. if the bootloader provides a valid struct bd_t). -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Best Linux tree for Xilinx support.
Leonid wrote: I deem such approach is not very good one. I'm using precisely same IP cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs which means (OK, may be cores are different somewhat for different FPGAs but low level Xilinx code is the same). That means at least 2 different CPU architectures (PPC and Microblaze). Most device drivers are outside the arch tree, only board specific configuration is inside. While there is a great deal of similarity between the microblaze and ppc code that would be under the arch tree's they are still as distinct as different architecures. Maybe there would be some way to share some of the code, but for the most part the similar or identical code falls outside the arch tree. A How EDK project parameters get into Linux kernel? This is huge issue which can be divided on several items. Xilinx has their own idea's and thus far they do not seem to fit well with the norms of Linux kernel developers. It is extremely unlikely the latter will change. I did the BSP for the Pico E1x series of boards. While it is based heavily on Grant's MLXXX work that I am trying to track, very little of it is even xilinx specific. One the key distinctions between FPGA based systems and typical systems is that the core is very very small. In a Pico E1x, you can only count on: A processor, an MMU, memory, and some serial (or pseudo serial) device capable of functioning as a console. Flash, Ethernet, Specific Uarts, Even interrupts and interrupt handling are all optional. A.2. There is also a question how these definitions get into .c and Make files. Petalogix has interesting solution when they bump all XILINX parameters to autoconf.h and .config files thus making them available for both compiler and make. What's your approach? With all respect to Petalogix and the significant work they have done, I can not see migrating all the xparameters.h values into .config being adopted. Besides little of none of those values are needed outside the core of the BSP. I am not particular enamored with the CONFIG_VIRTEX or CONFIG_VIRTEX_4 flags either. There is very very little that knowing the exact FPGA tells Linux. As an example Pico E12's, E14's and E16's are fundimentally very similar, despite having different form factors, being on different cards (CF, CardBus, ExpressBus), and using different Xilinx parts (sometimes on the same model) I beleive that the long term effort is to put everything into device tree's then the device information for the product is dynamically created, or stored in flash or otherwise provided to Linux at boot. But that is pretty close to the extent of my knowledge of device trees at this time. A.4. Is it assumed that Xilinx low level code will stay intact as it is supplied with EDK package or you are going to prepare special Linux Xilinx set (mostly because of name convention)? I do not beleive anyone is anticipating the Xilinx EDK code making its way into a kernel.org Linux source. B How drivers get registered - via platform devices structure in virtex.c file or something different? I beleive the current approach is mostly using platform devices - though individual drivers may vary. I beleive the longterm approach is to use device trees - I am not sure how the two interrelate. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Circular queue
Is there a standard linux datastructure and routines to manage circular queues ? I have a device that is not fundimentally different from a serial character device except it is faster and the fundimental data type is 36 bits large. I have coded my own routines to setup and maintain a simple circular queue, but I was hoping that there might be something more standard that already exists. Anyone know of anything ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
OT Re: [PATCH] Xilinx SystemACE device driver
Robertson, Joseph M. wrote: Hi, Ok, so outlook is a problem. The horror is that, where I work thats all I can use. They block all the outside systems like gmail, yahoo, etc. So under linux, I have to use the web access for outlook. ugh. Why I work here I don't know, they think all software HAS to be bought. Yet they want you doing Linux development ? I am an MSCE. I tried really really hard to like exchange/outlook. But after loosing too many weekends and holidays to emergency rebuilds of exchange mailstores I switched. Finding a better mail server proved trivial - I use exim/cyrus, but many many other combinations work well. The only time I have had to rebuild a cyrus mailstore was when the HD it was on coughed up 64K bad sectors in one night. I was able to recover 99% of everything, exchange would have chucked the whole mailstore. It has taken a long time for Open Source mail clients to offer competitive features to OutLook But almost every one I have ever tried has been more robust. If you are planning on doing embedded linux development you will be more productive the more immersed you are. While you can do alot of linux work from windows - one of my partners builds Linux apps inside visual studio, it is not the same. I have had clients with ludicrous self defeating [in]security like you have described. I have never met a firewall I could not pierce - included at some defense installations I am not supposed to talk about. I can pretty much always create a vpn back to my own servers and then do whatever I please. Joe Robertson x8259 [EMAIL PROTECTED] -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: TEMAC MAC address
Grant Likely wrote: On 7/11/07, Kevin Holland [EMAIL PROTECTED] wrote: Grant, How do I set the MAC address? Badly, with an ugly hack. :-) When my ML410 board boots its Hardware address is set to 0. I looked through the message boards and can't seem to find what Im looking for. Thanks for your help. I set the mac addr with some Virtex specific code in arch/ppc/boot/simple/embed_config.c. BTW, Please at least CC: the mailing list when asking questions. Pico cards pass the MAC address to linux via the board info struct - doesn't uboot etc. have a similar facility ? Pico registered a block of MAC addresses, uses them as card serial numbers and passes them via board info. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
TEMAC driver available
I have finally been inspired to complete my TEMAC driver to an alpha state. It nearly required dynamite - I had a client application where the Xilinx/MV TEMAC just did not work. Anyway, the sucker is done and I guess I will post it as soon as I have leaned it up if there is any interest. A brief description: Might optionally (as in used to badly) support the LL_TEMAC. Supports the more common PLB TEMAC ONLY in FIFO configurations. Autonegotiates. Is a reasonable approximation to a normal Linux network driver. i.e. does not require xilinx_comon, or xilinx_edk or . Aside from hooks into the Linux build system is entirely contained in a single reasonably sized source. Is extremely loosely based on older xilinx code from their Webserver sample application. For someone that desparately wants to see it immediately you can download http://www.picocomputing.com/files/linux/linux-2.6-pico.tar.bz2 but that is a complete 2.6.22-rc4 kernel.org linux source with the complete Pico BSP -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: booting zImage.elf
An elf file is not just a collection of bits exactly as they would be found in memory. The code in it may get loaded into several distinct regions, it may include information to allocate additional regions, the code may be relocatable or have relocation information. It is unlikely (maybe impossible) that you can create an elf file that you can just jump into. There are other file formats that you can build the kernel as that would more closely correspond to what you are after. Because I normally build zImage.elf files and my loader handles them well I am not experienced with creating other formats, but I think the u-boot documentation should give you some pointers. You do not convert the zImage.elf, you build the kernel with the image format that you want. zImage.elf is actually a very simple elf file, that performs some rudimentary initialization, and then decompresses what is really the kernel image into memory and executes it. The compressed image inside the zImage.elf is closer to what you are looking for. Shelley, Mike wrote: I've been trying to read up on how elf works and how to boot the linux kernel image with a custom boot loader. I can't seem to find anything about booting an elf image. I'm using a PCI Express XpressFX Board (which has a Virtex4), by PLDA, with DDR2 memory. I've got the kernel image booting using a BDI to load it. Now I need to get it to load without the BDI. The quick question is, Is it possible to load zImage.elf straight into memory, then jump to the address it was loaded to? If not, how do I convert the elf image into just a bootable image that I can jump to? I looked at the uboot code to load elf files, and it appears to copy the sections around. Is this necessary? Pointers on where else to look or how to do this would be greatly appreciated. Michael ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kernel and rootfs in ONE image?
If you are using 2.6 and you use initramfs, then typically you will get a single image that contains both the kernel, and the initial ramdisk. When you load and execute that image everything will get sorted out automagically. Frank Prepelica wrote: Hi all, in normal case you have got a kernel image and a rootfs image. Place that images into flash memory, set correct bootargs and it should work. But, is it possible to generate one image which includes the linux kernel and a rootfs, place that single image into flash memory and it should also work? Thanks in advance! Beste regrads Frank ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx git tree at source.mvista.com
Andrei Konovalov wrote: Hello, My Xilinx Virtex Development tree is now alive again. Please use the dev branch (master is just the ko copy): http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev Currently it has a patch to enable the framebuffer on ML403 and ML300 plus TEMAC driver that uses the PHY lib (FIFO mode support only). The TEMAC driver is work in progress. In the queue are SGDMA TEMAC support, and SPI driver (master only). My concern is that the TEMAC driver uses the level 1 drivers from EDK 9.1. The comments / opinions on how to get this driver (not the current incomplete version of course) accepted into the ko tree are very welcomed. I have an almost working FIFO TEMAC driver. It is similarly based. it started out based on the Trek webserver sample I spent probably 3-4 days de-EDKing it into something that fit into a single source and was closer to ko norms. It is based on approximately the EDK 8.1 stuff. You are welcome to it, if it could be helpful in anyway. I am all for getting an acceptable driver into the ko tree. I am not quite satisfied with how the current git repository is structured, and may rework it completely later. Thanks, Andrei ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx git tree at source.mvista.com
Andrei Konovalov wrote: Hi David, David H. Lynch Jr. wrote: I have an almost working FIFO TEMAC driver. It is similarly based. it started out based on the Trek webserver sample Is this a reference design by Xilinx? Linux based or standalone? I did a Local Link hard TEMAC driver - that I eventually got working. However, I could not find anyway to enable interrupts in the Local Link TEMAC so the driver was strictly polled and between that and other issues, perfomances was abysmal almost 50% of all inbound packets were dropped, we switched to the PLB FIFO TEMAC I stripped out all the SG and DMA stuff (as it is not in our hardware) and converted it to a fairly normal Linux ethernet driver. It sends, it receives, but I beleive it is not properly confirming to Linux that packets were successfully sent. In the interim I have been using the posted driver that uses the EDK. Until more recently that has lacked features like autonegotiation. I beleive its current flaw is primarily massive violations of kernel code style guidelines. I spent probably 3-4 days de-EDKing it into something that fit into a single source and was closer to ko norms. It is based on approximately the EDK 8.1 stuff. You are welcome to it, if it could be helpful in anyway. I am all for getting an acceptable driver into the ko tree. You could post your driver to the list when you think it is in good enough shape. If your driver is based on the linux TEMAC driver from EDK, it shouldn't be very different from my version (my added value is mostly replacing the custom PHY code with the PHY lib stuff). Then we could merge our drivers (or whatever would make sense). I would be interested to have a look at your current code just to see how much has it cost to de-EDK the FIFO part. You could email me your (even not quite working) driver privately if you want. I will email you a copy separately. I do not care what you choose to do with it. At the moment I have no time to take it further - something about asses, alligators and clearing swamps. Mostly I would just like to see a Linux friendly driver make its way into the kernel. I have almost exactly the same code working as a GHS integrity driver. In fact I sort of ported a mini shim layer to GHS to implement Linux SKB's under GHS. I did trip over something with GHS. If I was able to 64bit align the data part of the skb the send/receive code code be vastly simplified. I have not but I have not done that yet. Thanks, Andrei -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx git tree at source.mvista.com
Wolfgang Reissnegger wrote: Hi Andrei, David, It's great to hear that Andrei's git tree is active again. As you might have heard, Xilinx is in the process of setting up a git tree as well. Right now we are waiting for the new hosting machines to be installed. We should get those machines up and running shortly (within a couple weeks). Absolutely fantastic - however I think kernel.org would be happy to host your git tree for you as well as a few other places. Those are locations people would look for public git trees. I beleive you can still excecise some control. I beleive they are free - though I suspect kernel.org would not mind contributions from xilinx. Currently the tree is based on mainline and adds support for MicroBlaze. I also intent to merge Grant Likely's virtex-dev branch, the framebuffer patch and the various other contributions that are out there. You might want to look at the Microbalze-uClinux mailing list as well as petalogix. They are not using git yet, but they are puching the microblaze towards kernel org inclusion. We are also in the process of changing our internal coding guidelines to match the common Linux style (e.g. u32, u16 types, 8 char wide (tab) indentation, curly brace location etc) to make it easier to integrate code into the kernel and push it upstream. For me the most significant issue is the bazillion layers of nested macro's and includes. The kernel style guides atleast to me are primarily about the readability and understandability of the code. not where the curly brackets are. I'll send an update once we have the server up and running. Thanks, Wolfgang -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help need for WindRiver EST SBC8260 Board
techie mj wrote: Hi All, For my project work(Packet filter) we are planning to buy a used WindRiver EST SBC8260 board The board you purchase should as closely as possible resemble your actual product/target. Alot depends on what you are actually trying to accomplish. If you are working towards a manufacturing a custom piece of hardware of your application, Then similarity of hardware is of high importance. And it may be likely that you have to create or buy a BSP for your taget - particularly if you are supporting multiple OS's. If you are doing fairly generic work and the target is the OS's, not the specific hardware, then find a board that is already supported by all the OS's you are after. Before Pico had any of their boards available, I used a Mac Lombard powerbook I purchased on eBay as a target. It was cheap, and runs Linux surprisingly well. I am new to this. So i request everyone to suggest me what i should look for while buying the board.My development environment will be LINUX may be vxworks in future. 1) My dealer is providing only the Board. ( 4MB-SIMM flash,16MB-SDRAM DIMM, 8kb- 8 bit EEPROM, 2MB- 8 bit Flash, 4MB SDRAM (Local Bus), RS-232, 10/100 Base-TX Ethernet) Is it enough -or whether i need any extra addon cards Again it depends on what you are trying to accomplish. The first embedded system I worked on had 256 bytes of memory, had a 1Mhz clock, and toggle switches. The more minimal the hardware in resources and performance the more difficult the development process tends to be. 2) Do i need to buy JTAG debugger or any Is it possible to debug the code without JTAG/BDM Same as hardware and resources. I do not have a BDM. Many on this list would think I am crazy. I have worked with very powerful debugging tools - but very very often, all they do is overload you with data. On occasion they can be very convenient. But most of the time the FIRST thing I do starting with new hardware is find some way of generating output - usually in the least number of assembler instructions possible. One is really really nice - give me an LED and a bit to flash it and I can debug anything. I needed little more than a virtual LED and printf's to get Linux working on my target. But I had issues with GreenHills Integrity that required both a JTAG as well as a minimal handwritten software debugger. 3) what are the cables i need 4) Can i directly download the bootcode from my PC to the Board through ethernet/serial port 5) Can anyone provide me the user manual for the above board. any weblinks are also good 6) any other points Thanks mjose ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC_OCP and ppc_sys problem while running kernel2.6 on ML403
[EMAIL PROTECTED] wrote: Hi, all I met the CONFIG_PPC_OCP related problem while running MontaVista linux based on kernel 2.6.17 on Xilinx ML403.I have been confused with some questions about CONFIG_PPC_OCP and ppc_sys.Any reply from anyone is appreciate. From which version did the kernel.org tree stop using the OCP infrastructure and begin to use the ppc_sys infrastructure?Why did this change occur?what disadvantages dose the OCP infrastructure have? The LSP generated by EDK is still using the OCP infrastructure,so when it overwrites the kernel,mistakes happen.Is there any BSP version using ppc_sys which can solve the OCP problem? Also,the ppc_sys dosen't seem to support Virtex board well because I saw most patches supplied drop both ppc_ocp and ppc_sys.What disadventages dose ppc_sys have?Is patching the only method to solve this problem? Are there any patches supporting 2.6.17? Expect your reply,thanks! I am not sure about versions, but I think OCP has been dropped for mainline Linux Kernel sources for about a year. Even the replacement will be somewhat obsoleted when the Xilinx BSP's move from the arch/ppc tree to the arch/powerpc trees. There is a some significant divergence between the Xilinx EDK approach to supporting Linux and what is in the mainline kernel source. Slowly mainline kernel support for various Xilinx devices is maturing. If your product does not require much support for hardware that is not yet in the mainline sources I would highly recommend using the mainline Kernel source. Currently there is support for the Xilinx ML300 and ML403 (with support for Xilinx PIC, and UartLite) in the distribution kernels. My source (following the distribution source closely) for Pico cards is available on Pico's Web Site, www.picocomputing.com. Grant Likely seems to be the staging point for moving broader Xilinx IP support into the mailine kernel source. Grant maintains a xilinx-dev git tree that is even closer to the source trees from kernel.org that includes deeper support that is in the pipeline. I beleive with the exception of the Xilinx TEMAC, the only EDK component needed is an xparameters.h file for your particular hardware. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: virtex_devices.c
Grant Likely wrote: Although this point is actually moot because platform_bus pretty much goes away when we move to arch/powerpc. We'll be using of_platform_devices instead (which map onto nodes in the device tree). That I got and as I pound away at all of this I keep thinking my time would be better spent figuring out device trees. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: virtex_devices.c
Grant Likely wrote: I think I understand what you're describing, but I'd need to see your code snippits to be sure. Can you send me the relevant patches? As soon as I have something working I will post it. At some point if I get inspired I may take a wack at crafting generic approach using an early serial mini driver. But for the moment my choices are: add a few more 8250 specific #ifdefs to kill off most of the conflicting code in virtex_devices.c and adapt my own code that is already in my BSP. This is the simplest and does the least damage to your code. Considering the fact that the whole purpose of virtex_devices.c is to massage the mess of #defines that is xparameters.h in to something more parsable, then extra #if defined() test may not be a big deal. This is not just about virtex_devices. Supporting early Output on something other than an 8250 requires #ifdef's all over creation. This is just screaming for a more generic solution. But that needs to happen without much increase in complexity However, I need clarification. Are you talking about early serial port support, console support or regular serial devices? While I am specifically dealing with one area. More broadly I am talking about all Output prior to the real serial driver coming up. This seems to be the pre-linux stuff in arch/ppc/boot/simple. You just added a uartlite_tty.c there. I have had one for a long time. but that is pretty trivial. and the slightly more complex arch/ppc/syslib/uartlite_dbg that is used by the progress stuff and for a bit prior to the early serial driver code. I do not think you have code for this - but I do. These bits are only critical when something early goes completely to crap. But then they are important. For example; on one of my boards here I've got both 16550 and uartlite devices on the same board and it works fine for serial port access. I've also got another design with only uartlite and another with only 16550. Each of these scenarios should work with the code that is now in mainline (but there are some issues still). This is also relevant to me because I have another pseudo serial device that I support in exactly the same way as UartLite. It is unique enough to our hardware that it is likely of little interest to anyone else. But it means everytime I look at a UartLite issue, I am looking at a keyhole issue too. It means that everywhere there is an 8250 specific solution to a problem, I end up with a 3 way fork. While support for early non-8250's is lite - there are others besides the uartlite and my keyhole. I rarely use JTAG and other hardware debugging tools. It is critical for me to be able to output information at most every part of the kernel load process. plat_serial8250_port is used because it is the structure used by the platform bus to connect the 8250 driver to 8250 devices. This is of course specific to the 8250 driver. The Uartlite ports are simple enough that they don't need a *_platform_data structure; instead the resources table in a virtex_platform_devices[] entry is sufficient to describe the device to the platform bus. You should be able to do the same thing with your keyhole device registration. By substituting uart_port for plat_serial8250 I end up with something generic. I do not understand the rational behind the plat_serial structs. It is not like u-boot or something else passes them, they seem to be entirely a kernel creation, they contain no information that is not in uart_port which is generic for anything that pretends to be a serial device, and using the plat_serial8250 means individually copying values from that struct to a uart_port. By just substitution uart_port for plat_serial8250 I end up with code that is exactly the same for anything that looks like a serial device. Now, early serial is still a problem. When using zImages, you must make sure that only one of CONFIG_SERIAL_UARTLITE_CONSOLE and CONFIG_SERIAL_8250_CONSOLE is set. If they are both set, then it will not compile. (But this is just a zImage boot wrapper issue. The kernel proper should work fine). Also, early serial in the kernel proper is not implemented in driver which is in mainline, but console and regular serial access is supported. To add early serial support, I think virtex_early_serial_map() should be reworked to scan the whole virtex_platform_devices table looking for either uartlite, serial8250 or keyhole devices. That is basically what I am doing. The UART macro(s) in xparameters, are changed to use uart_port element names. All serial/pseudo serial devices are setup uniformly the same. Serial devices are distinguishable in the uart_port struct by their .type field, In the rare instances I need to distinguish there are if's or
Re: [RFC] uartlite driver MicroBlaze compatability
John Williams wrote: I think that's Grant's approach of using in/out_be32, and the real base address (ie not +3) is the only logically correct solution. Trying to track how every permutation maps in every possible scenario is more than my brain can handle. What I do know is that throwing an arbitrary +3 offset in is incredibly confusing. While I pointed out that the Xilinx docs sugguest implimentations with regshifts of 0,1 2 - and I beleive I have seen xilinx example code that sugest they may have somehow implimented UartLite on occasion with less than 32bit registers. The stock GreenHills Integrity default UartLite driver presumes a regshift of 0. But I have never seen an 8 or 16 bit Uartlite. However before either my driver or Peters showed up there was one posted to this list that used dcr. My suggestion would be to handle port IO inside serial_in()serial_out() functions like the 8250 driver (and about 1/3 of the other serial drivers) do. While in a perfect world we should be able to compile the UartLite driver without change for an x86 if somehow that can be created, atleast with all the io moved to two functions, adjusting for different regshifts, endians, requires a very limited number of localized changes. I would be happy to submit a patch to do that but I can not test it because I can not get Peter's driver to work with my hardware. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 2/5] [PPC] Merge common virtex header files
Grant Likely wrote:
Is the redboot bd_info structure already in the kernel tree? We could
use a config option to select between the u-boot and redboot
structures for all virtex platforms. That would keep the uglyness
down to a minimum.
g.
There are a plethora of bd_info's in the kernel tree. I think that
u-boot is probably the most common,
but the u-boot one is huge and full of cruft.
There are also likely to be any number for board/loader combinations
that are not in the kernel.
I have cut an pasted ours below - not that I am trying to sell it.
But I would prefer that if there is a bd_info struct that it be defined
by the board not virtex.h or virtex.c.
//Information passed to program when it is executed.
typedef struct _BOARD_INFO
{uint32_t bi_signature; // 0x00 valid bi signature
uint32_t bi_memMax; // 0x04 DRAM installed, maximum byte
address
uint32_t bi_intfreq; // 0x08 Processor speed, in Hz
uint32_t bi_busfreq; // 0x0C PLB Bus speed, in Hz
uint32_t bi_version; // 0x10 local pico number format #.##,
eg 3.09
uint8_t *bi_cmdline; // 0x14
uint32_t bi_capabilities;// 0x18 Pico capabilities mask
uint32_t bi_debug; // 0x1C Pico flags mask
uint32_t bi_flashstart; // 0x20 start of FLASH memory
uint32_t bi_flashsize; // 0x24 size of FLASH memory
uint32_t bi_envSize; // 0x28 environment size
uint8_t bi_enetaddr[6]; // 0x2C Local Ethernet MAC address
uint16_t bi_cflags; // 0x32 console flags
char *bi_envP;// 0x34 pointer to environment string
uint32_t bi_model; // 0x38 0x0E16'FX', (ie 0x0E164658) etc
uint32_t bi_resv;// 0x38 reserved
} BOARD_INFO; // 0x40
--
Dave Lynch DLA Systems
Software Development:Embedded Linux
717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net
fax: 1.253.369.9244Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.
Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction.
Albert Einstein
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: I always encouter this simple error message compiling 2.6 for ML403 UART 16550
Grant Likely wrote: Oops; that patch won't work. Try this one instead. What really needs to be done is to create some kind of mini-driver architecture for the boot and debug serial drivers. There are only something like 4 or 5 simple functions, and in many cases only putchar() needs implimented. The whole boot/debug early serial stuff is highly and unescesarily 8250 specific. While there are several alternatives, these typically involve numerous #ifdef's and then end up being board specific. Being able to output data, before linux has loaded, or before the standard serial drivers have initialized is probably not important for working systems, but is incredibly useful when trying to bring up a new board - particularly if you are trying to do so with silly scopes, logic analyzers, and other electronic gizmo's give me an output bit and an LED to hang on it, and I can flash the world -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ram not at 0? anyone?
rvk wrote: I've learned a little more, looking at PPC_MEMSTART from include/asm-ppc/page.h, and it seems there is some relevant infra. However I'm still worried about the tophys() and tovirt() implementations used by head_4xx.S. Can anyone comment who has experience with RAM not at physical 0? I don't have the board yet, but it will be Xilinx Virtex 4 ppc405. You might want to try posting to the uClinux list. Boards running uClinux are much more likely to have odd memory configurations. I am fairly certain that you can get a board running with base memory elsewhere than 0. But I also suspect it will add substantially to your time. My hardware engineers told me that memory at 0 was going to be impossible, until I told them it make take 2-3 more months to get Linux running. Miraculously I got new firmware with memory at 0 the next day. The PPC405 is part of the V4 FPGA, regardless of the rest of the board design, what the ppc sees is almost certainly controlled by the FPGA. After you get your board working with an odd memory map, then you will have to maintain it. Your board will become the test case for flexible memory handling for future Linux development. That means future grief for you. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: git tree
Grant Likely wrote: I haven't quite decided yet. The -temac and -sysace branches are a bit of an experiment. I thought it might be a good idea to maintain the drivers in seperate branches so it is easy to get a diff on just that driver; but the individual drivers are pretty seperate anyway (in different directories). I think I'll probably drop the -temac and -sysace branches, and just maintain all my changes in the -dev branch. The -forupstream branch is specifically for patches that are due to go upstream. I'll add patches there when I think they are suitable for mainline, and post them to the list. I would greatly appreciate pointers to so reference for using git for kernel development. I have looked through most of the howto's and have a basic competence with git. I am looking for something more like how to manage development with possibly multiple devices/projects. Not necescarily what is possible, but what Standard Operating Procedure for most developers. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using Linux 2.6.19 with Xilinx ML405
PM Do you know if I can use it for early serial in the same way as an PM 8250? Unfortunately not. I started working on some patches for this some months ago, but got stalled doing other stuff. I doubt it will get integrated before the move to arch/powerpc. I posted working early serial patches as part of an earlier uartlite driver (not PK's) http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021545.html The patch is a single big patch with compete board support for the Pico E12 cards, but it includes complete boot2bash uartlite support, including early serial. The uartlite code much more closely follows the 8250 code. The early serial portions probably would work asis with PK's driver. Though I can't confirm that as PK's driver does not work on my hardware. A newer version of the same big patch is at http://www.picocomputing.com/software/files/Installers/coLinux/Pico-2.6.patch.bz2 When I have more time and am more proficient with git I will likely break it up into individual pieces. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ram-disk root file system
Dan Wilson wrote: We are attempting to use an initrd ram-disk as the permanent root file system for a MPC8541-based system. We are using ELDK 4 to cross-compile, and are running linux 2.6.15 kernel, with u-boot 1.1.6 as our bootloader. I built an initrd file system, compressed it, then ran mkimage against it, and it seems to be successfully loaded by u-boot, and linux sees the initrd file and claims to have mounted it. However, it then reports that it is unable to find any files on the mounted root file system, as shown in the log below. I added some additional diagnostics to show what the error codes were, and what was happening, but do not understand what I might have done wrong. If I boot linux from an NFS system or from compact flash, I am able to mount the image and see all the files, so I believe the initrd file system was created correctly. I had similar problems with a permanent initramfs filesystem. It is possible your problem has nothing to do with your filesystem. First, I presume the debugging you added was in init/main.c. Before you attempt to exec init, you can add code to open anyfile that you want on the ramdisk. opening a file requires less things to be right than exec'ing and that may isolate your problem further. I beleive you can enable system call tracing and find out more about where things are going off the rails. You can also write a trivial hello world - one that does not use any libraries and very little code, and see if you can exec that. When you boot Linux NFS - are you using the same linux kernel ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Deerfield Internet connection
DAVE YOU THE MAN THANKS B At 06:00 PM 6/15/2006 -0400, David H. Lynch Jr. wrote: Comcast finally installed internet at Deerfield. There is a Linksys 802.11a+b+g Wireless Router in DTL's upstairs office. The Wireless is setup using WEP security. The ssid is deerfield the WEP key is either One Ring or 40faad1ede Barbara persuaded Comcast to bring in the service. I beleive it is on a month-month basis. -- Dave Lynch DLA Systems Software Development: Embedded Linux 717.627.3770 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://www.dlasys.net http://www.dlasys.net/ fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.1.394 / Virus Database: 268.8.4/364 - Release Date: 6/14/2006 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.394 / Virus Database: 268.8.4/364 - Release Date: 6/14/2006 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Perl
Lee Revell wrote: On Tue, 2006-11-14 at 18:08 +0100, Wolfgang Grandegger wrote: Lee Revell wrote: I've been trying to cross compile Perl for a PPC440 board and it just isn't happening. Perl is probably the least amenable application to cross compiling I've found. I tried the instructions in the Cross/ directory of the Perl distro but they don't work - "sh Configure" fails on my target because it expects a full C development environment, which won't fit. Is there any easy solution? Can someone send me a binary? Configure and make perl natively on your target platform. I have done it some time ago with the ELDK. I've almost got the cross compile method described in INSTALL to work (using SSH to the target). But it just hangs forever at "Checking how to flush all pending stdio output...". Argh. Compiling natively on the target is not an option, the perl build process has too many dependencies. It depends on stuff fron GNU coreutils like /bin/comm that is not available in busybox. Does no one out there have a binary they are willing to send me? Lee You can also use something like a Mac PowerBook with ppc4xx crosstools as a build and test environment. I did most of my early link port work that way, though I now use crosstools under colinux. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development: Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244 Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Xilinx UART Lite 2.6.18 driver
Peter Korsgaard wrote:
static int __init ulite_console_setup(struct console *co, char *options)
{
+ int i, ret;
struct uart_port *port;
-
+ struct platform_device *pdev;
+
if (co-index 0 || co-index = ULITE_NR_UARTS)
return -EINVAL;
port = ports[co-index];
/* not initialized yet? */
- if (!port-membase)
- return -ENODEV;
+ if (!port-membase) {
+ /* We might be early console */
Is this really necessary? The platform probe get's called quite early, E.G.:
Breakpoint 2, ulite_probe (pdev=0xc01c84d0) at drivers/serial/uartlite.c:392
There is a substantial time/code difference between the time
ulite_console_setup() is called and the time the platform device is
initiallized.
If you are actually doing board bringup, you want output as soon as
you can get it and you do not want to have to stuff calls to
ppc_md.progress() to do so.
Regardless, I think this is an issue of style and personal preference.
392 {
(gdb) print __log_buf
$1 = 5Linux version 2.6.19-rc3 ([EMAIL PROTECTED]) (gcc version 3.4.5) #19
Fri Oct 27 16:39:00 CEST 2006\n6Barco ThinLite (V2P) [EMAIL
PROTECTED]\n7Entering add_active_range(0, 0, 15360) 0 entrie...
You can always use the ppc_md.progress() stuff for really early
debugging if needed. I would prefer to keep this workaround out of
uartlite.c if it isn't needed.
I will absolutely agree that trying to resolve the the
dissimilarities between the console_setup() call and the platform device
init is ugly.
But I would have changed the platform device init code to use
the uart_port structure in the platform device data as all the other
drivers that have early console support do.
At some point I suspect a cleaner more structured approach to
modularizing the relationship between early serial code and serial
drivers will force this issue one way or another.
But for now, if you are not going to bother making console_settup()
work you might as well not put the rest of the early serial code in at all.
--
Dave Lynch DLA Systems
Software Development:Embedded Linux
717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net
fax: 1.253.369.9244Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.
Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction.
Albert Einstein
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Xilinx UART Lite 2.6.18 driver
Peter Korsgaard wrote: "David" == David H Lynch [EMAIL PROTECTED] writes: Hi, DavidPeter's driver uses the IORESOURCE requests to pull platform David data. Most other serial platformdevices pull a uart_port David object. My limited understanding of IORESOURCE is that it is David not sufficiently deep to support the parameters that are needed David to support UartLite such as a DCR flag and a regoffset. I'm still not convinced that DCR access and variable register offsets are needed - But it can always be added (through a seperate struct in platform_data) - Patches are welcome. It does not matter whether you or I are convinced. It matters whether there are people that need it. Xilinx has a reference design that uses DCR. While I have never tripped over an actual implimentation that uses DCR there are others on this list that have. The same with interrupt-less support if the changes are not too intrusive. Right now I can not get your driver to work. I spent alot of time trying to fix it and got nowhere. I can not get it to receive at all, and I can not get it to send after switching from the console driver without dropping characters. I am very busy with other things right now and it is going to be a long time before I have time to look at your driver again. In the meantime, my own driver works - atleast for me. And it is out in the real world on production systems. The most instrusive changes is likely to be fixing whatever is causing yours to drop characters - the problem is worse when I patch your driver to be timer driven - but that is likely because your service routines blindly presume it is safe to transmit - true on a Tx empty interrupt, but not on a timer tick. But what matters is not whether the changes are intrusive, but whether they produce a better result. DavidYou are welcome to do that. I already patched his driver to David work with my early console support as well as adding the David boot-bash stuff similar to yours. But I gave up actually using David it when I could not get it to work. Which is odd as I've gotten positive feedback from others. I am glad somebody is using your driver and finding it works. But we are all better served by fixing the failure cases. It is not particularly odd at all. The UartLite despite its simplicity is worse than a normal driver - different FPGA implimentations can vary. Normal drivers for fixed inflexible hardware often do not work accross differing implimentations, why would you expect something like UartLite to be invariant ? One of the other reasons for implimenting polling is because a polled driver tends to work accross wider hardware variations. You can not make state assumptions in a poll routine, and if the poll routine does nto run then the rest of the OS is hosed. Even today, flakey hardware interrupts are not unheard of. I would also ask what data rates you and others with Working UartLites are using ? The cases I am dealing with run at 57600 and 115200 respectively - it is not that odd for driver problems to manifest themselves only or more frequently at high baud rates. DavidNext time I get an opportunity I am going to try to setup an David ml403 to atleast verify that Peter's driver is working there. Great. Without being difficult - don't hold your breath. It is something I would like to do, but I do not have infinite time. -- Dave Lynch DLA Systems Software Development: Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244 Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: uartlite with 2.6.17 kernel and kernel early text messages
Robert Corley wrote: I am still trying to get the UARTLITE to work with 2.6 and a plb_temac design. I am using EDK 7.1. I have generated the edk files and copied xparameters_ml300.h to arch/ppc/platforms/4xx/xparameters.xparameters_ml403.h In an effort to get past the Rebooting to System ACE Configuration Address 6... message, I have selected support for early boot texts over serial port in kernel debugging. I do not think Peter's driver actually supports early boot texts. I beleive the patches David Bolcsfoldi posted add early boot support. If you can not get that working I posted a driver in January (as part of a patchset for the Pico E12) that has early boot support - though on inspection David's patches looked like they should work. FYI, I'm using Peter's patches to create the uartlite.c and associated files and have selected the uartlite using make menuconfig. The first error is as follows: athena startup_network # make ARCH=ppc zImage.initrd CHK include/linux/version.h CHK include/linux/compile.h dnsdomainname: Unknown host CC arch/ppc/syslib/gen550_dbg.o arch/ppc/syslib/gen550_dbg.c:36: error: `RS_TABLE_SIZE' undeclared here (not in a function) arch/ppc/syslib/gen550_dbg.c:38: error: empty scalar initializer arch/ppc/syslib/gen550_dbg.c:38: error: (near initialization for `rs_table') arch/ppc/syslib/gen550_dbg.c:36: error: storage size of `rs_table' isn't known arch/ppc/syslib/gen550_dbg.c:36: warning: 'rs_table' defined but not used make[1]: *** [arch/ppc/syslib/gen550_dbg.o] Error 1 make: *** [arch/ppc/syslib] Error 2 Unless you actually have an 8250 based Uart in your system - and you are not configured for one, then arch/ppc/syslib/gen550_dbg should NOT be getting built. Proper early boot text support for the UartLite requires both a replacement for this AND changes to use those instead of gen550_dbg.c so, I modified the gen550_dbg.c file to #include the xparameters.h, where the RS_TABLE_SIZE is defined but still get more errors. Here they are: You do not want to touch gen550_dbg.c You need a new uartlite_dbg.c and Makefile and other changes to use it. CHK include/linux/version.h CHK include/linux/compile.h dnsdomainname: Unknown host CC arch/ppc/syslib/gen550_dbg.o arch/ppc/syslib/gen550_dbg.c:37: error: `XPAR_UARTNS550_0_CLOCK_FREQ_HZ' undeclared here (not in a function) arch/ppc/syslib/gen550_dbg.c:37: error: initializer element is not constant arch/ppc/syslib/gen550_dbg.c:37: error: (near initialization for `rs_table[0].baud_base') arch/ppc/syslib/gen550_dbg.c:37: error: `XPAR_INTC_0_UARTNS550_0_VEC_ID' undeclared here (not in a function) arch/ppc/syslib/gen550_dbg.c:37: error: initializer element is not constant arch/ppc/syslib/gen550_dbg.c:37: error: (near initialization for `rs_table[0].irq') arch/ppc/syslib/gen550_dbg.c:37: error: `XPAR_UARTNS550_0_BASEADDR' undeclared here (not in a function) arch/ppc/syslib/gen550_dbg.c:37: error: initializer element is not constant arch/ppc/syslib/gen550_dbg.c:37: error: (near initialization for `rs_table[0].iomem_base') arch/ppc/syslib/gen550_dbg.c:37: error: initializer element is not constant arch/ppc/syslib/gen550_dbg.c:37: error: (near initialization for `rs_table[0]') make[1]: *** [arch/ppc/syslib/gen550_dbg.o] Error 1 make: *** [arch/ppc/syslib] Error 2 Questions: 1.Now, is this an issue with the UARTLITE driver or is it just not supported for early messaging? Peters does not support early boot texts. Both David's and my drivers do as do David's patches to Peter's driver./ 2. What am I missing w.r.t. getting something out of the serial port? 3.I am assuming that the boot args for a initrd boot are: console=ttyUL0 ip=off root=/dev/ram rw, correct? Presuming you have no other serial device I think you should not need any console= argument at all. -corley ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: which driver for uartlite with 2.6.17?
David Bolcsfoldi wrote: Hi :-) Good question. Well I was unaware of the fact that there were other uartlite drivers so you should take mine off that list. Peter's driver is slated for inclusion in the mainline and I am currently in the process of adding a few things to it. For 2.6.17 support you should probably just remove the IRQF_DISABLED flag and change IRQF_SAMPLE_RANDOM to SA_SAMPLE_RANDOM in the request_irq call and it should work. I am unaware of any other important differences between the two releases affecting this driver. Cheers, David On 10/13/06, Robert Corley [EMAIL PROTECTED] wrote: All, Based on what was posted recently, it appears that there is more than one uartlite driver floating about. Can someone please inform me of which driver works for which kernel? Here is what I see D. Lynch2.6.15polled, (Pico E12 board specific?) My driver supports polled and/or interrupt driven use - if you want polled you set the IRQ to -1. It should not be Pico E12 specific - I just have never tested it on anything but the Pico E12 and E14 boards. I do not think I have posted a patch that ONLY includes the UartLite. At the moment it seems like it would just confuse things. Peter and I uses fairly different Platform device initiallization. Mine is based on the 8250 code which makes it much easier to impliment early boot text support. You can actually diff my driver against the 8250 driver and mostly will find it is a subset. My driver also has boot-bash support. supports regshift values other than 2. I recently patched my driver to use the major and minor nodes Peter obtained through lanana.org as well as use his ttyUl0 naming. I am not sure which version of the kernel the patch supports, but I have been running my driver from 2.6.13-2.6.18. But aside of patch issues, all of the drivers below should work across many versions. Yoshio Kashiwagi -Nissin Systems - Late January 2006. Also provided a UartLite driver that was a drop in replacement for the version I posted in January. Yoshio's version uses DCR. His should also provide early boot text support. I am not sure if he posted his version but he provided me with a copy with a GPL license so I can post it or email it if someone wanted. P. Korsgaard2.6.18interrupt driven, official lanana.org nodes Is only interrupt driven, only supports a regshift of 2. Does not work for me, but aparently does for some others. Does not have early boot text support - Davd Bolcsfoldi has provided patches for that - though it would also be trivial to use my driver and replace my uartlite.c with Peter's and get early boot text support - aside from initialization issues - which appear to be ignorable, early boot text and the driver are very independent. David Bolcsfoldi appears to have a few other quality related patches to Peter's drivers which I have not had a chance to try. D. Bolcsfoldi2.6.18interrupt driven David's also has early boot text support. David also provided early boot text support as a patch to Peter's driver. patch locations: D. Lynchhttp://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021592.html P. Korsgaardhttp://lkml.org/lkml/2006/9/13/71 D. Bolcsfoldihttp://ozlabs.org/pipermail/linuxppc-embedded/2006-October/024697.html Comments? Yes, I think including anything in the Kernel at the moment is premature. While I wish Peter would have started from something that already existed. He did do the work to register the major and minor numbers and run his through linux-serial - though I think his submission was premature. I know my driver has a few failure cases - none of which matter in my environment. I also know it has not been tested on other uartlite implimentations. The same is true of all the other UartLite drivers listed. Peter's and mine diverge in design almost as much as you can diverge while still following the Linux serial driver model. I deliberately patterned mine after the 8250 - there are pro and con arguments for that, but atleast you know. I am very familiar with serial hardware - I have written serial code for the past 25 years. I am less familiar with Linux Serial drivers. I deliberately patterened mine on an existing driver I knew to be well supported, robust, and tolerant of disparate and flakey hardware - partly because of my lack of depth of Linux Serial Driver knowledge and partly because I knew that anything that worked well for 8250's would likely work well with other uarts. I do not know what Peter's is based on. I have tried to reconcile my patches with Peter's driver - basically implimenting the functionality I have Peter is missing. But Peter's driver does not work on my boards. I have spent a great deal of time trying to fix that, and come to the unhappy realization it will probably take a great deal more to solve that - much more than it took to
Re: [PATCH] Xilinx UART Lite 2.6.18 driver
David Bolcsfoldi wrote: No I did not know that unfortunately, it could have saved me some work. You are of course right and I'd much prefer to make changes to your driver instead of writing another one. I am sorry you put so much effort in. However, you could have checked the archives. I think there are atleast 3 different UartLite drivers posted since January. It would be really nice if we could all standardize on one driver. But I would not sweat this too much. Peter ignored the fact that my driver was posted here in January, too and went off and wrote his own which does not have early serial port - yours and mine do. and does not have polled support - mine does. and does not have DCR support - there is another one out there that has DCR support. and I can not get to work on my hardware - the only Xilinx V4 based product that actually defaults to a UartLite I've noticed that in the probe function it tries to get some resources from the platform_device structure but it looks like that this operation will always fail unless I add a 'uartlite' platform device or have I completely misunderstood how platform devices work? Peter's driver uses the IORESOURCE requests to pull platform data. Most other serial platformdevices pull a uart_port object. My limited understanding of IORESOURCE is that it is not sufficiently deep to support the parameters that are needed to support UartLite such as a DCR flag and a regoffset. Counting yours that is 4. But yes, I will try to add support for the things I need to this driver instead, most importantly early console support and move the #defines for register offsets and such into a separate header file per Grants comments You are welcome to do that. I already patched his driver to work with my early console support as well as adding the boot-bash stuff similar to yours. But I gave up actually using it when I could not get it to work. Next time I get an opportunity I am going to try to setup an ml403 to atleast verify that Peter's driver is working there. Cheers, David On 10/12/06, Peter Korsgaard [EMAIL PROTECTED] wrote: "David" == David Bolcsfoldi [EMAIL PROTECTED] writes: Hi David, David here's a set of patches that adds support for Xilinx UART lite David devices. It has been tested on an ML403-FX using xapp902 David (ml403_ppc_plb_temac) using a 2.6.18 kernel and a BusyBox David userspace. I guess you didn't know, but there already exists a uartlite driver! It unfortunately didn't made it into 2.6.19-rc1 because Russell stopped maintaining serial stuff, but it's in -mm. It also has an official lanana.org assigned set of device nodes. I didn't look at your patch yet, but I think it would be more useful to add any features missing to my driver than writing yet another driver (I think we're up to 3 now). -- Bye, Peter Korsgaard ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development: Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244 Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] Xilinx UART Lite 2.6.18 driver
also:
your driver is strictly interrupt driven.
I need polled for the Pico E12 - which my driver an early
version was posted in January, supports.
Somebody else needs DCR support.
David Bolcsfoldi wrote:
Hi,
here's a set of patches that adds support for Xilinx UART lite
devices. It has been tested on an ML403-FX using xapp902
(ml403_ppc_plb_temac) using a 2.6.18 kernel and a BusyBox userspace.
This is my first patch for the Linux kernel, so please be gentle :-)
David
diff -urN 2.6.18/arch/ppc/boot/simple/Makefile
patched/arch/ppc/boot/simple/Makefile
--- 2.6.18/arch/ppc/boot/simple/Makefile 2006-10-04 14:31:15.0
-0700
+++ patched/arch/ppc/boot/simple/Makefile 2006-10-07 10:34:32.0
-0700
@@ -205,6 +205,7 @@
endif
boot-$(CONFIG_SERIAL_MPC52xx_CONSOLE)+= mpc52xx_tty.o
boot-$(CONFIG_SERIAL_MPSC_CONSOLE) += mv64x60_tty.o
+boot-$(CONFIG_SERIAL_XUL_CONSOLE)+= xuartlite_tty.o
LIBS := $(common)/lib.a $(bootlib)/lib.a
ifeq ($(CONFIG_PPC_PREP),y)
diff -urN 2.6.18/arch/ppc/boot/simple/misc.c
patched/arch/ppc/boot/simple/misc.c
--- 2.6.18/arch/ppc/boot/simple/misc.c2006-10-04 14:31:15.0
-0700
+++ patched/arch/ppc/boot/simple/misc.c 2006-10-07 10:27:34.0
-0700
@@ -48,7 +48,8 @@
#if (defined(CONFIG_SERIAL_8250_CONSOLE) \
|| defined(CONFIG_VGA_CONSOLE) \
|| defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
- || defined(CONFIG_SERIAL_MPSC_CONSOLE)) \
+ || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
+ || defined(CONFIG_SERIAL_XUL_CONSOLE)) \
!defined(CONFIG_GEMINI)
#define INTERACTIVE_CONSOLE 1
#endif
diff -urN 2.6.18/arch/ppc/boot/simple/xuartlite_tty.c
patched/arch/ppc/boot/simple/xuartlite_tty.c
--- 2.6.18/arch/ppc/boot/simple/xuartlite_tty.c 1969-12-31
16:00:00.0 -0800
+++ patched/arch/ppc/boot/simple/xuartlite_tty.c 2006-10-07
10:29:30.0 -0700
@@ -0,0 +1,74 @@
+/*
+ * Xilinx UART Lite support.
+ * Right now it only works over UART0 and none other.
+ *
+ * Copyright (C) 2006 David Bolcsfoldi dbolcsfoldi at gmail.com
+ *
+ * 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 asm/io.h
+#include platforms/4xx/xparameters/xparameters.h
+
+#define XUL_STATUS_REG_OFFSET 8 /* status register, read only */
+#define XUL_SR_TX_FIFO_FULL 0x08/* transmit FIFO full */
+#define XUL_SR_RX_FIFO_VALID_DATA 0x01/* data in receive FIFO */
+#define XUL_RX_FIFO_OFFSET 0 /* receive FIFO, read only */
+#define XUL_TX_FIFO_OFFSET 4 /* transmit FIFO, write only */
+
+static inline int is_xmit_full(unsigned int address)
+{
+ return ((in_be32((volatile unsigned *) (address +
XUL_STATUS_REG_OFFSET)) XUL_SR_TX_FIFO_FULL) == XUL_SR_TX_FIFO_FULL);
+}
+
+static inline int is_recv_empty(unsigned int address)
+{
+ return ((in_be32((volatile unsigned *) (address +
XUL_STATUS_REG_OFFSET)) XUL_SR_RX_FIFO_VALID_DATA) !=
XUL_SR_RX_FIFO_VALID_DATA);
+}
+
+unsigned long serial_init(int chan, void *ignored)
+{
+ switch (chan) {
+ #ifdef XPAR_XUL_UART_0_BASEADDR
+ case 0:
+ return XPAR_XUL_UART_0_BASEADDR;
+ #endif
+ #ifdef XPAR_XUL_UART_1_BASEADDR
+ case 1:
+ return XPAR_XUL_UART_1_BASEADDR;
+ #endif
+ #ifdef XPAR_XUL_UART_2_BASEADDR
+ case 2:
+ return XPAR_XUL_UART_2_BASEADDR;
+ #endif
+ #ifdef XPAR_XUL_UART_3_BASEADDR
+ case 3:
+ return XPAR_XUL_UART_3_BASEADDR;
+ #endif
+ default:
+ goto out;
+ }
+
+out:
+ return -1;
+}
+
+void serial_putc(unsigned long com_port, unsigned char c)
+{
+ while(is_xmit_full(XPAR_XUL_UART_0_BASEADDR));
+ out_be32((volatile unsigned *) (XPAR_XUL_UART_0_BASEADDR +
XUL_TX_FIFO_OFFSET), c);
+}
+
+unsigned char serial_getc(unsigned long com_port)
+{
+ while(is_recv_empty(XPAR_XUL_UART_0_BASEADDR));
+ return in_be32((volatile unsigned *) (XPAR_XUL_UART_0_BASEADDR +
XUL_RX_FIFO_OFFSET));
+}
+
+int serial_tstc(unsigned long com_port)
+{
+ return !(is_recv_empty(XPAR_XUL_UART_0_BASEADDR));
+}
+
diff -urN 2.6.18/arch/ppc/boot/common/misc-common.c
patched/arch/ppc/boot/common/misc-common.c
--- 2.6.18/arch/ppc/boot/common/misc-common.c 2006-10-04 14:31:15.0
-0700
+++ patched/arch/ppc/boot/common/misc-common.c2006-10-07
10:33:28.0 -0700
@@ -57,7 +57,8 @@
#if
Re: Problem with initrd
[EMAIL PROTECTED] wrote: I am trying to get Linux running on the PPC of a Xilinx V4-FX12 FPGA. I am using the Linux 2.6.17.9 kernel (I have also tried 2.6.17.1 with the same results) and have gotten through the kernel initialization to the point where it mounts the root file system. At this point I can an Oops and a kernel panic. I traced the kernel and found it was happening on the gunzip of the ramdisk image. I tried without compressing the ramdisk image and I got a slightly different error. I have attached this output as well. I am not a kernel expert, but I am guessing it is having trouble accessing the RAM for the ramdisk. Can anybody offer some advice? Try 2.6.18 or 2.6.16 . There were compression/decompression problems in 2.6.17 for the ppc. These may be your problem. Thanks, Glenn With compress ramdisk image: loaded at: 0040 0052B13C board data at: 00529124 0052913C relocated to: 004050F0 00405108 zimage at: 00405805 004D072E initrd at: 004D1000 00528981 avail ram: 0052C000 1000 Linux/PPC load: console=ttyS0,9600 console=tty0 root=/dev/ram rw Uncompressing Linux...done. Now booting the kernel initrd start c04d1000 end c0528981 Linux version 2.6.17.9 ([EMAIL PROTECTED]) (gcc version 3.4.5) #32 PREEMPT Tue Oct 3 23:25:12 EDT 2006 Xilinx Virtex-II Pro port Port by MontaVista Software, Inc. ([EMAIL PROTECTED]) Built 1 zonelists Kernel command line: console=ttyS0,9600 console=tty0 root=/dev/ram rw Xilinx INTC #0 at 0x4120 mapped to 0xFDFFE000 PID hash table entries: 2048 (order: 11, 8192 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 257408k available (1424k kernel code, 368k data, 80k init, 0k highmem) Mount-cache hash table entries: 512 checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 350k freed NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 8192 bind 4096) TCP reno registered io scheduler noop registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 1) is a 16450 RAMDISK driver initialized: 1 RAM disks of 4096K size 1024 blocksize loop: loaded (max 2 devices) nbd: registered device at major 43 eth0: using fifo mode. eth0: Xilinx EMAC #0 at 0x8040 mapped to 0xD100, irq=0 eth0: id 2.0a; block id 0, type 8 mice: PS/2 mouse device common for all mice TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RAMDISK: Compressed image found at block 0 allocated in buffer allocated window buffer make crc gunzip Oops: kernel access of bad area, sig: 11 [#1] PREEMPT NIP: C004115C LR: C0041148 CTR: C00FA29C REGS: c0421610 TRAP: 0300 Not tainted (2.6.17.9) MSR: 00029030 EE,ME,IR,DR CR: 35035093 XER: E000 DAR: 1000, DSISR: 0080 TASK = c0529b10[1] 'swapper' THREAD: c042 GPR00: C0041148 C04216C0 C0529B10 0001 0001 C04216A8 GPR08: 1000 0400 35035099 9620 0001 C04216D0 GPR16: C018CD50 C04C88A0 C052FC08 1000 0001 C052FCA8 GPR24: 0014 C045 1000 C01E3F20 1000 1000 NIP [C004115C] generic_file_buffered_write+0x4ec/0x5bc LR [C0041148] generic_file_buffered_write+0x4d8/0x5bc Call Trace: [C04216C0] [C0041148] generic_file_buffered_write+0x4d8/0x5bc (unreliable) [C0421780] [C0041A10] __generic_file_aio_write_nolock+0x4d4/0x50c [C0421810] [C0041DB8] generic_file_aio_write_nolock+0x28/0x98 [C0421830] [C0041EA0] generic_file_write_nolock+0x78/0xa8 [C04218D0] [C00657F8] blkdev_file_write+0x20/0x30 [C04218E0] [C005B400] vfs_write+0xc8/0x190 [C0421900] [C005B5A0] sys_write+0x4c/0x8c [C0421930] [C01AD2D4] flush_window+0x34/0xe4 [C0421950] [C01AD8B8] inflate_codes+0x468/0x4b0 [C04219A0] [C01AE0E0] inflate_dynamic+0x64c/0x690 [C0421EE0] [C01AEA1C] rd_load_image+0x8f4/0x106c [C0421F40] [C01AF33C] initrd_load+0x4c/0x304 [C0421F70] [C01ACCB8] prepare_namespace+0xa8/0x11c [C0421F90] [C0002580] init+0x1b4/0x280 [C0421FF0] [C00051FC] kernel_thread+0x44/0x60 Instruction dump: 48006591 2f9d 419c001c 7ec3b378 3881 4800441d 48120851 2f93 409efbe8 8061005c 81210064 2f83 92e9 93090004 41be0008 48006555 Kernel panic - not syncing: Attempted to kill init! 0Rebooting in 180 seconds. With uncompress ramdisk image: loaded at: 0040 008D313C board data at: 008D1124 008D113C relocated to: 004050F0 00405108 zimage at: 00405805 004D072C initrd at: 004D1000 008D1000
Booting problems
I am booting a compressed initramfs kernel. I have hit what appears to be a size issue. simply adding more data to the initramfs source directory, or adding even a small amount of unused code to my kernel causes it to hang after relocation during boot. The point of failure varies with the size of the kernel image. I have tried blindly jiggering with the CONFIG_ADVANCED_OPTIONS setting with no noticable effect. The total zImage.elf size is just shy of 3Mb. Does anyone have an idea what I need to do to be able to load a larger image ? ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ethernet driver for Linux kernel 2.6 running on ML403
Grant Likely wrote: Avast! After getting quizzed on IRC about this off-the-cuff comment, I should probably clarify. Since the Xilinx IP could be wired up to a ublaze core or an off-chip processor, the drivers still need to use a platform bus attachment to keep it all cross platform. So, replace above comment with the following: Populating the platform device with static code during initialization is sooo last year. Time to hack device trees to populate it instead. So I got another X V4 board. I hacked in the Platform device stuff from you ml403 code with changes needed for my hardware. and my brain is slowly begining to actually grasp what is going on - I am begining to grasp the platform devices big picture (over a mountain through a spyglass in the fog) Where do I begin with Device Trees ? The vague Picture I have is the have something to do with some datastructure that Mac's typically create at or prior to boot. And that for embedded systems we are building them externally compiling them and then attaching the compiled device tree to our project. I got a Xilinv V4 device currently with a Pic, UartLite, TEMAC, Flash and Keyhole (pseuodo serial host interface). Of those it is only certain that the flash will always be there. We have bit images with Keyhole only, Uartlite only TEMAC only, Sometimes we have a Pic sometimes not. I was trying to get to the point were I could dynamically add what was there to Platform devices during initialization. If Device trees are static, then do they even apply to what I have to deal with ? Please pardon my ignorance. -- Dave Lynch DLA Systems Software Development: Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244 Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kernel Blocked
I have a Xilinx ppc405 working out of the 2.6.18-rc7 linux-2.6 git tree - with patches for my board. I beleive you are either just at the end of the code in arch/ppc/boot/simple - which is mostly the initial load/decompress. Or just started the code in arch/ppc/kernel/head_4xx.S You ought to be able to grep Now booting to establish a last know good point. There is also a pretty good call tree in comments of arch/ppc/platforms/4xx/xilinx_ml403.c. While small parts are ml403 specific, much of it is generic. However, if you have not gotten into arch/ppc/kernel/head_4xx.S then you are not at the begining yet. [EMAIL PROTECTED] wrote: Hi All, First, if anyone wants to use linux 2.6.18-rc2-g73a589b5 with ppc, he should patch inflate.c from linux 2.6.18-rc7 to fix Uncompressing failure problem. But new problem is: when relocate and gunzip functions are finished, and 'Now booting the kernel' is shown, the system is halted. My bootloader is working fine with linux 2.6.13, could anyone tell me what the next function executes and how to check this kind of problem, thanks. Wei ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ethernet driver for Linux kernel 2.6 running on ML403
Grant Likely wrote: On 9/13/06, Aleck Lin [EMAIL PROTECTED] wrote: Hi, I'm able to boot Linux 2.6 on ML403 board (with a ramdisk file system). However, during the kernel booting, it complains that "No network devices available," So I figured I probably didn't enable the ethernet driver in the kernel. From doing "make menuconfig", under "Device Drivers" -- "Network device support" -- "Ethernet(10 or 100Mbit)", I checked the box of both "Ethernet (10 or 100Mbit)" and "PowerPC 4xx on-chip Ethernet support." I then save/exit the menuconfig to compile the kernel again. I've attached the error output at the bottom. The virtex eth device is not the same as 4xx on-chip Ethernet, so CONFIG_IBM_EMAC will not work. You need the xilinx_enet driver (which is not in mainline). It might be in MontaVista's 2.6 tree. I think people have posted patches for it to this list, so try searching the archives. (I don't have a link off the top of my head.) The MV 2.6 Xilinx_edk based TEMAC driver has been posted to this list several times. As of the last incarnation I tried it had no MII/PHY support and you had to manully change the speed of the driver 10/100/1000 by editing the code. Otherwise it worked with the PLB FIFO TEMAC, that I am using, and should with others. I have a polled driver that works with the LL TEMAC. I am nearly finished a PLB FIFO TEMAC driver that includes working autonegotiation and does not use the Xilinx_edk. But right now it has a receive problem - packets come in they look good but linux silently discards them. I have virtually the same code working under GHS Integrity. -- Dave Lynch DLA Systems Software Development: Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244 Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ethernet driver for Linux kernel 2.6 running on ML403
Michael Galassi wrote:
It is also worth noting that as released in MVL pro 4.0.1 it only
supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
tagged as deprecated in the current version (8.2.01i) of Xilinx's
EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
lengths to break compatibility with older versions. This will
presumably be fixed next month when it is rumored that wonderful new
things will come from Xilinx. In the mean-time it is possible, though
neither simple, nor fun, to create Virtex4 designs with the older IP.
Fortunately, I have little to do with the firmware.
Unfortunately, after the firmware is in the product, I am the guy
who has to make the drivers work.
I am also not straight - though I am somewhat clearer, on exactly
what any given flavor of TEMAC is.
As best as I can tell, the V4 FX chipsets contain some dedicated
hardware that forms the basis for the TEMAC.
(or possibly several TEMAC's depending on how it is built).
Separately Xilinx provides a plethora of wrapper logic, that allows
you to implement a slew of different incarnations.
All similar yet different at the same time. Ranging from the Local
Link TEMAC which is the simplest to the
PLB SG DMA driven TEMAC which is probably the most complex.
Then there is an assortment of PDF's from Xilinx, none of which
quite match whatever you might have.
And at the risk of Goring somebodies Ox, the MV/EDK based drivers
may/may not have the attribute of
being portable accross multiple OS's, but they seem to pretty much
deliberately violate almost every style
quideline for Linux drivers. Linux is written in C, not
preprocessor Macros.
For anyone at MV I have ticked off - Sorry, I am sure it is
brilliantly written preprocessor Macros.
-michael
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ethernet driver for Linux kernel 2.6 running on ML403
John; My guess would be that as the whole xilinx drivers/edk stand, even with the virulent support of this list I would not bet on their being accepted upstream. Nothing in the Linux Kernel that I am aware of resembles them. There has been on ongoing holy war in LKML over getting reiser4 accepted as experimental, one of the major issues being coding style. The style of reiser4 is alot closer to Linux norms than the Xilinx EDK code. The current Xilinx approach is supposed to easily give us board support for varying IP's accross several platforms. I have been providing board support for Pico Computing's Xilinx V4 based offerings for about a year, and I have been unable to take advantage of any of that. I have done board bringup for two OS's. While I have been able to benefit from the work of other's on this list, and I have been able to occasionally use some code coming from Xilinx - mostly as a reference, I have two products supporting two operating systems, with a small collection of variable peripherals. None of this uses the Xilinx EDK. I deliberately postponed work on the ethernet drivers in the hope they would be finished by the time I finished everything else. In the end I had to write my own. I am not trying to bash Xilinx or Monta Vista. What I am questioning is whether the approach that Xilinx is currently using, aside from other problems, may actually run counter to its goal. If the Xilinx EDK could give us the support we need for the IP's we use. If it adapted easily between OS's, and IP versions. And if the code was as current as the IP's themselves. Maybe the Xilinx EDK would be vindicated. Certainly many of us would use it. While I happen to personally adhere to 98% of the Linux Style guidelines - I here many of my own views express ed in them, I am not a fanatic. I am happy if my work improves Linux. But in the end I pay my mortgage and feed my family. I will use the resources that get the job done. Style is secondary. But my honest expectation is that MV/Xilinx EDK support will always lag way behind what I am trying to do, and/or be incompatible with the goals and objectives of my clients. For me the code coming from Xilinx/MV is most useful as a reference. I have ranted about mismatches between documentation and hardware - but that is not something new or specific to Xilinx. What code has leaked out has proven useful - often after several days work turning it into something actually readable, as a reference - Oh, that is how that bit really works I would be happy to be proven wrong - but I do not expect to be. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MAC driver issues
I am trying to get a network driver working. It sends - I can capture the output with Etherreal and it looks good. It receives - I can dump the received packets when the come in and they look ok to me. BUT, If I try to ping another host, first Linux sends and ARP broadcast, the appropriate client sends an ARP response. Etherreal is happy with both. My driver gets the response - The driver says the packet lenght is 64 bytes, which includes something like 14 bytes of padding at the end. But the actual packet looks perfect exactly like what etherreal says it should (and what I get when I capture a received ARP packet in another driver). At the end of the recive interrupt the skb is passed to Linux with the netif_rc(ndev) function. This returns SUCCESS. However, the paket never gets handed of to the ARP protocol - I put some debugging in there and I never see it, while if I switch to a different NIC driver nearly the identical ARP packet gets processed by arp inside Linux. I have tried to chase this down, but I can't follow what is going on inside of all the /net/core/dev.c etc. Has anyone seen something similar to this ? Does anyone have a clue where I can find some info on trying to follow something through netif_rx to see where things are going off the rails ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein
PPC beginner questions
Wade Maxfield wrote: I'm new to the PPC and I have a few questions. I have written a driver in the past for the X86 family, using i/o ports, but it was kernel 2.0 and i/o ports are not mmu handled. I've been looking through the archive and I am slowly growing more confused. The PPC MMU is pretty simple compared to the x86. Basically the MMU unit is a peice of hardware that maps virtual addresses to physical addresses. Its use is enabled/disabled by two bits in the PPC Machine Status register - 1 for instructions, 1 for data. The MMU itself is basically a 64 entry lookup table. Virtual address X corresponds to physical address Y. When a request is made for an address that is not in the 64 entry MMU table things become more complex - an exception is generated and code inside Linux searches its tables to find the correct entry to stuff into the MMU. NORMALLY there is no correspondence between physical addresses and virtual ones. But it is possible (and might be useful for debugging) to stuff an entry where physical=virtual. If you look inside head_4xx.S for CONFIG_SERIAL_TEXT_DEBUG or something like that you should see how to do it. However manually stuffed entries in the MMU will eventually get blown away. I spent a week trying to trace a problem caused by that down. We are using Xilinx with PPC built in. The PPC has a memory management unit. All of the IP we've added is mapped to physical addresses. 1. Can I access the memory the peripherasl are mapped to directly within the driver without going through functions? if NOT, then Do I use 1. ioremap(), Once you have done the ioremap(), you can use the address returned exactly the way you would have used the physical address previously. 2. request_mem_region(), 3. request_region() 4. something else? 2. Are there any gotcha's with the ppc 405 that Xilinx uses that I should know about? Are you doing board bringup ? If you are not bringing up a new board - then the big gotcha's should already be covered. If you are doing board bringup - I would recommend following the existing xilinx packages closely. thanks, wade ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060822/47e616d3/attachment.htm
ioremap() fails for 64 MB
is ioremap() failing or is vmalloc failing ? ioremap should just assign a virtual address to a physical address - does it actually allocate anything ? I beleive I am ioremap()ing a greater than 64MB Flash ROM and I do not think it is failing. Alex Zeffertt wrote: Phil Nitschke wrote: Hi all, I have 2 GB memory on a 7448 processor, and want to reserve a huge chunk of it at boot-time, then ioremap() it into the kernel space inside a device driver. So far I've succeeded with 64 MB, but can't go any higher, as mm/vmalloc.c tells me: allocation failed: out of vmalloc space - use vmalloc=size to increase size. I remember reading in Linux Device Drivers that you can use the bigphysarea patch to allocate large memory, as long as you do it at boot time. It seems it's been ported to 2.6 too: http://lwn.net/Articles/32/ Alex ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060822/b1943af6/attachment.htm
MTD Flash Howto ?
I need to put together a filesystem driver for the flash in the Pico E-12. I think I have a pretty good grasp of what I need of the FileSystem end of things. But I am less certain of the peices needed to get from the flash to the block driver that I assume underly's the FileSystem. I have enabled MTD, and configured a starting address and size. I got a signon banner. How can I tell if it has really found my flash and if it actually knows the type of flash it found - in my instance Spansion S29GL512N. I have found some documentation covering details, I think I am more interested in something that gives a more zoomed out view. Is anyone aware of a relevant howto ? Maybe some web pages on the end-end process of going from flash devices to filesystems over flash ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060804/8936e6a8/attachment.htm
MTD Flash Howto ?
Thanks; I looked at the Denx stuff that was a good start. But raised some questions: I have a single device. I presume that means it is 8 bits wide, and constitutes a single Bank. I guess I have to query the Hardware people, on that. What exactly drives CONFIG_MTD_I? and CONFIG_MTD_B? A hard disk partition is usually reflected by data structures (a partition table) written to the Disk. Am I correct in assuming that these are in drivers/mtd/maps. In my instance all the flash belongs to a single file system There is a single reserved block at the begining, but it is reflected in the filesystem structure not the partitioning. So as I understand things I have a single partition. When I ran menuconfig, I indicated that I did not need/had a single partitions - would that be the correct choice ? There is a platform ram map that seems to allow defining the flash region in a platform data structure - is that a viable alternative to a machine specific map file ? Is it limited to just RAM. Prior to loading a filesystem driver shouldn;'t I get some message indicating that mtd detected my specific type of flash ? or Is that queriable inside /proc ? Ned W. Rhodes wrote: The book Building Embedded Linux Systems has a good section on the use of flash file systems. When you boot, you will see something like this, depending on the type of flash driver you have. Make sure you have defined your mtd map in kernel/drivers/mtd/map. JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. JFS: nTxBlock = 965, nTxLock = 7720 Then if you have the MTD partitions correctly identified, the kernel will show you something like: CBG flash bank 0: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0031 Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled Creating 2 MTD partitions on CBG flash bank 0: 0x-0x0180 : ffw1 0x0180-0x0200 : filesystem1 Once booted you can look at /proc/mtd and you should see the partitions something like: [root at lbg ]# cat /proc/mtd dev:size erasesize name mtd0: 0180 0002 ffw1 mtd1: 0080 0002 filesystem1 Your mileage may vary depending on the type of flash you have and all the configuration options, but that is basically how to tell that things are mapped and ready for use. Ned W. Rhodes Software System Group 703.812.5072 x100 -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein
Xilinx TEMAC
Ameet Patil wrote: Did you happen to get an Ethernet mac going on the virtex2 or virtex4 with the 2.6 kernel? Nope! :-( Rumour has it that Montavista is soon going to release the source for 2.6 kernel to run on Xilinx platforms. I have 2 different TEMAC's working under 2.6 with a V4. The MontaVista driver that has been posted on the list that I think is from MontaVista for the PLB TEMAC with very minor modifications to get it to work at speeds other than GigaBit. A driver I wrote for the LocalLink TEMAC that works limpingly. I have been unable to figure out how to get a receive interrupt from the LocalLink TEMAC so receives are polled and performance is poor. I have pretty much abandoned work on it - my client wants the smallest possible FPGA footprint BUTanother OS I am porting requires interrupt driven IO and we are looking for a single minimal hardware implimentation for all platforms. Anyway, if anyone wants the LL TEMAC in its current state I can post it. Currently it sends fine. It drops about 50% of all received packets - but that is probably debugging overhead and poll rate tuning. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein
Booting Linux Kernel without bootloader
Grant Likely wrote: I've got a similar situation on my Virtex-4 platform. The FPGA takes care of all device initialization. However, the kernel is loaded of a CF card via a *slow* JTAG interface. Loading an uncompressed image is more time consuming than loading a compressed image and uncompressing it in software. I am working with the Pico E-12. It is a CF formfactor device. It has only a pseudo Parallel/Jtag interface exported through the CF connector Pico calls the Keyhole Port, and A UartLite, and TEMAC off some mini connector. Pico has their own monitor program that fits in 32K of ram inside the FPGA that loads and executes ELF files (or FPGA bit images) from a very simple FileSystem (basically a linked list). Then they have Host software to Read/Write the Flash, update files in Flash, ... that works primarily through the Keyhole. I just build the Kernel as an ELF file, update the ELF File in Flash and tell it to boot that file and away it goes. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein
[Fwd: [PATCH][RFC] ppc32: TEMAC driver for ML403]
Edward Bockhoefer wrote: Thank you for the reply David, I have started the montavista 10/100 enet port from the xilinx edk generated 2.4 driver to the 2.6 driver. Unfortunately, I can't post the driver port publicly because it's not GLP'd, as far as I know. We only needed a 10/100 mac, so we didn't bother with a TEMAC. I will work on this more today. If you want to send me your TEMAC code, please do so. I can always use the reference. The original message for the GB TEMAC 2.6 patch is below. It is from Andrei Konovalov. I think it is just a newer version of the 2.4 Driver. Regardless it just worked for me. I had to make a very minor change - I added an u32 spd to the private data structure, initialized it to 10 (I am on a 10Mhz Net), and found every reference to 1000Mhz replaced it with lp-spd; There was one place I needed a switch statement to load the appropriate value. I think there were only 3 really trivial changes. I would post my changes but I am not setup to post them as a patch right now. If you really want them I will just send my adaptor.c and you can use everything else from the patch referenced below. I have also attached my Local Link TEMAC code. That is basically a single file driver. Again I am not able to provide it as a patch at the moment. It (much like the PLB TEMAC driver) requires a platform data entry for the LL TEMAC in your Board support code. Though it could be fairly trivially changed to work from defines. I beleive there are only 2 critical values - the DCR base address, the TEMAC memory address. There is an IRQ value, but I can only get the LL TEMAC to generate PHY interupts, so the driver is polled. It does work albeit with lots of dropped packets, but that is probably debugging code and optimizing the poll rate. The driver is solely my own work based loosely on several other drivers, and is GPL'd. According to my client LL TEMAC performance has tested abysmally in comparision to the PLB TEMAC, however the kicker was the inability to generate rx interupts. We are working on other OS ports, and some do not have strictly polled options, so for now the LL TEMAC is on the back burner. Of course I have learned an incredible amount about Linux Network Drivers as well as now having a reasonable understanding of the differences between the assorted Xilinx TEMAC's Original Message Return-Path:linuxppc-embedded-bounces+dhlii=dlasys.net at ozlabs.org Received: from colinux.fixit1.net (colinux.fixit1.com [216.37.233.220]) by xm.dlasys.net (Cyrus v2.2.12-Debian-2.2.12-4) with LMTPA; Tue, 14 Mar 2006 00:34:38 -0500 X-Sieve:CMU Sieve 2.2 Received: from ozlabs.org ([203.10.76.45]:45331) by colinux.fixit1.net with esmtp (Exim 4.50 #1 (Debian)) id 1FIny3-0002KK-J4 for dhlii at dlasys.net; Mon, 13 Mar 2006 09:24:16 -0500 Received: from ozlabs.org (localhost [127.0.0.1]) by ozlabs.org (Postfix) with ESMTP id 628F067B23 for dhlii at dlasys.net; Tue, 14 Mar 2006 01:17:33 +1100 (EST) X-Original-To: linuxppc-embedded at ozlabs.org Delivered-To: linuxppc-embedded at ozlabs.org Received: from mail.dev.rtsoft.ru (unknown [85.21.88.2]) by ozlabs.org (Postfix) with SMTP id A94B7679E2 for linuxppc-embedded at ozlabs.org; Tue, 14 Mar 2006 01:17:21 +1100 (EST) Received: (qmail 31931 invoked from network); 13 Mar 2006 14:17:16 - Received: from unknown (HELO ?192.168.1.108?) (192.168.1.108) by mail.dev.rtsoft.ru with SMTP; 13 Mar 2006 14:17:16 - Message-ID: 44157EEF.5000900 at ru.mvista.com Date: Mon, 13 Mar 2006 17:17:19 +0300 From: Andrei Konovalov [EMAIL PROTECTED] User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linuxppc-embedded list linuxppc-embedded at ozlabs.org Subject:[PATCH][RFC] ppc32: TEMAC driver for ML403 X-BeenThere:linuxppc-embedded at ozlabs.org X-Mailman-Version: 2.1.7 Precedence: list List-Id:Linux on Embedded PowerPC Developers Mail List linuxppc-embedded.ozlabs.org List-Unsubscribe: https://ozlabs.org/mailman/listinfo/linuxppc-embedded, mailto:linuxppc-embedded-request at ozlabs.org?subject=unsubscribe List-Archive: http://ozlabs.org/pipermail/linuxppc-embedded List-Post: mailto:linuxppc-embedded at ozlabs.org List-Help: mailto:linuxppc-embedded-request at ozlabs.org?subject=help List-Subscribe: https://ozlabs.org/mailman/listinfo/linuxppc-embedded, mailto:linuxppc-embedded-request at ozlabs.org?subject=subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linuxppc-embedded-bounces+dhlii=dlasys.net at ozlabs.org Errors-To: linuxppc-embedded-bounces+dhlii=dlasys.net at ozlabs.org Here: http://source.mvista.com/~ank/paulus-powerpc/20060309/ is an StGIT patchset against 516450179454de9e689e0a53ed8f34b896e8651c branch 'master' of
XUPV2P, Kernel 2.6.17 boot problem
Benjamin Heyne wrote: Dear all, I am currently trying to get the 2.6.17.1 Linux kernel running on the Xilinx Virtex. I have the 2.4 kernel up and running - No problems there... But when using the 2.6 kernel (have copied xparameters file, patched for using TEMAC driver) with the same hardware configuration the following happens: loaded at: 0040 0061813C board data at: 00616124 0061613C relocated to: 00405148 00405160 zimage at: 0040585D 00615F42 avail ram: 00619000 2000 Linux/PPC load: console=ttyS0,9600. Uncompressing Linux...inflate returned FFFB exit Zlib was upgraded with 2.6.17. The updated Zlib is broken on ppc32. I am pretty certain it is fixed in 2.6.18-rc3 Now, I am not really sure where to start searching for the bug (I just want to implement some drivers - not the kernel itself ;-). The zImage.elf file is about 2MB large. Did anyone encounter a similar error? Does anyone have some hints where to look at for debugging, or what might be wrong? Thanks in advance Best regards -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein
Xilinx hard TEMAC
Rick Moleres wrote: That is the correct distinction between soft and hard. Just know that in this case the soft TEMAC (whether LL TEMAC or PLB TEMAC) uses the hard TEMAC, and the hard TEMAC by itself is not that useful. First, thanks, your remarks have been enormously helpful. I have successfully put together a Driver for the TEMAC currently used in the Pico E-12. I am still having some difficulty corresponding this TEMAC implimentation to any of Xilinx's documentation. It is Exactly the TEMAC supported by the Xilinx uCOSII Treck Web Server application. It seems to be extremely minimal. Basically a DCR interface for most things that closely matches the GSRD documents. and TX and RX FIFO's that I can't seem to find documented anywhere, but I have working based on the Treck WebServer code. I am have two remaining problems and then I am done. The first is I am currently doing polled I/O. The transmits happen as they are requested and the receives are picked up ona a timer interrupt. But I am dropping about 50% or more of the receives. I will work that out myself eventually. The second is that this driver will serve as the basis for a driver in other Pico supported OS's. Some of which have no means of doing Polled Receives. And I can not get interrupts working. Since my hardware does nto match anything perfectly - except that Treck Webserver application and that does not do interrupts. I am reading all the Xilinx TEMAC Documents and the GSRD documents reference an IRENABLE register and an IRSTATUS register, I cobbled something together assuming that they were access much as the other DCR registers in that block and I assumed the bits in IRSTATUS and IRENABLE matched the definitions of those in larger TEMAC implimentations. It appeared after I enabled TX and RX complete interrupts that when I have received data available the IRSTATUS register has the Bit set for an Rx interrupt. All fine - except that no interrupt actually occurs. I can force interrupts from the PHY using the same IRQ so the IRQ is connected correctly and programmed correctly. Other TEMAC implimentations seem to have a GIE - Global Interrupt enable Bit, but I do not have a clue where to look here. What I could get out of the Xilinx Webset GSRD seems to be a Linux driver that uses the DMA unit and that generates its own interrupts. I don't think I have the DMA in my bit image. Anyway any clues as to where I can find some useful docs on Interrupt handling for the LL_TEMAC that is used by the uCOSII WebServer application ? Thereis a Linux driver for the LL_TEMAC that comes with GSRD, but my group's efforts go toward the PLB_TEMAC as that is the EDK IP we want to promote and whose drivers we'd like to see in kernel.org. You should be able to go to http://www.xilinx.com/gsrd to get the GSRD design, and inside of that design somewhere you'll find a Linux 2.4 driver for the LL TEMAC. ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060729/ffac300e/attachment.htm
Reg. virtual address space in embedded linux
Is there a reason you need to map and unmap physical/virtual memory
every time you do a read or write ?
I think the norm is to map the physical region in your device driver
in its initialization code and unmap it if the driver exits.
After that you should be able to read and write your chip as you
wish. If the registers are RW then you should be able to dump them by
reading them at whatever later time you choose.
jagannathanjay at aim.com wrote:
Hi all
We are porting third party driver code from vxworks to Embedded linux
in MPC 8260 under a evaluation platform from Embedded Planet in linux
kernel space.
The first step we carried out was reading the chip id and we were able
to read the chip id correctly.
For reading the chip id we used the routine ChipReadMemory in the
attached text and we were able to retrive the chip id successfully.
Subsequently when we write and read from Chip Specific Control Status
registers ,it didn't work.
I checked the manual and the Chip Specific Control Status registers
have RW access.
Any inputs on how to check if the write we made to virtual address
succeeds?
Is there a way to dump the linux virtual address and examine the write
we made ?
Regards
Jay
*Check Out the new free AIM(R) Mail*
http://pr.atwola.com/promoclk/100122638x1081283466x1074645346/aol?redir=http%3A%2F%2Fwww%2Eaim%2Ecom%2Ffun%2Fmail%2F
-- 2 GB of storage and industry-leading spam and email virus protection.
int ChipReadMemory(unsigned int arg_phys_addr,unsigned int *memValue)
{
void *virt_addr = NULL;
unsigned int phys_addr = 0;
phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
virt_addr = ioremap(phys_addr, 4);
if(virt_addr == NULL)
{
printk(ChipReadMemory: unable to perform ioremap \n);
return -1;
}
*memValue = readl(virt_addr);
iounmap(virt_addr);
return 0;
}
int ChipWriteMemory(unsigned int arg_phys_addr, unsigned int arg_val)
{
void *virt_addr = NULL;
unsigned int phys_addr = 0;
phys_addr = DEVICE_BASE_ADDRESS + arg_phys_addr;
virt_addr = ioremap(phys_addr, 4);
if(virt_addr == NULL)
{
printk(ChipWriteMemory : unable to perform ioremap \n);
return -1;
}
writel(arg_val,virt_addr);
iounmap(virt_addr);
return 0;
}
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Dave Lynch DLA Systems
Software Development:Embedded Linux
717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net
fax: 1.253.369.9244Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.
Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction.
Albert Einstein
-- next part --
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060725/ea78f5f8/attachment.htm
