Hi, <br><br> ok, so I have managed to give it some OF support in a preliminary way(see patch). But now, I am facing serious problems which I am finding difficult to tackle. I understand that maybe these problems have to do partially or entirely to the Xilinx ML403. Let me explain myself: First of all, I don't know of anyone else who has used it for the ML403 with the XPS_EPC , so there might be some particularities I should specifically take care of. <br>
<br> First of all, I see a resetting problem. When I load the kernel with my board from a powered off state to a powered on state it behaves differently that if I just to try to load the kernel again with the board powered on (see ERROR 1 below). I have seen that the reset line in the c67300 is connected to the fpga and for sure, to take care of it one would need to do it through a third gpio line outside. This would be to make a hard reset. Looking at this old specific driver that I have found for kernel 2.4.20 ( <a href="http://www.sysf.physto.se/%7Eattila/ATLAS/Digitizer/Testbench/System_ISE_SoftMAC/linux/software/uClinux-2.4.x/drivers/usb/cy7c67300/" target="_blank">http://www.sysf.physto.se/~attila/ATLAS/Digitizer/Testbench/System_ISE_SoftMAC/linux/software/uClinux-2.4.x/drivers/usb/cy7c67300/</a> ) I see that the hard resets are common using the ugly gpio method. <br>
<br> With the board on, if I reload the fpga programming and kernel image into memory and set the PC to run properly, it gives different errors. Sometimes ERROR2 and some other times ERROR3. When ERROR2, the processor halts when calling WARN_ON(!res) and in the second, the interrupt handler keeps writing to the output endlessly. <br>
<br> I have added some printks to trace the problem and the OF support is simply a rewriting of the normal platform_driver registration. Any ideas?<br><br>Jorge<br><br>-- ERROR 1 (just after power on-- <br>Generic platform RAM MTD, (c) 2004 Simtec Electronics<br>
usbmon: debugfs is not available<br>C67X00_DBG:c67x00_of_probe() - Request memory region<br>C67X00_DBG:c67x00_of_probe() - Allocating data structs<br>C67X00_DBG:c67x00_of_probe() - Configuring c67x00 device<br>C67X00_DBG:c67x00_of_probe() - Configure platform data based on the device-tree data<br>
C67X00_DBG:c67x00_of_probe() - hpi.regstep: 2<br>C67X00_DBG:c67x00_of_probe() - SIE_config: 1<br>C67X00_DBG:c67x00_of_probe() - SIE_config: 21<br>C67X00_DBG:c67x00_of_probe() - Low-level initizalization <br>C67X00_DBG:c67x00_ll_hpi_reg_init(): Reg:324 written=0x00 ; read: 0<br>
C67X00_DBG:c67x00_ll_hpi_reg_init(): Reg:328 written=0x00 ; read: 0<br>C67X00_DBG:c67x00_of_probe() - Registering IRQ<br>C67X00_DBG:c67x00_of_probe() - Trying to register IRQ:17 @ 17<br>C67X00_DBG:c67x00_irq() - Handling IRQ number 57005<br>
�����;�L�=?� : Not all interrupts handled! status = 0xdead<br>C67X00_DBG:c67x00_irq() - Handling IRQ number 57005<br>C67X00_DBG:c67x00_of_probe() - Low-level reset<br>C67X00_DBG:c67x00_ll_reset() - Send mbox<br>C67X00_DBG:c67x00_ll_reset() - recv_msg<br>
C67X00_DBG:ll_recv_msg() - calling wait_for_completion_timeout <br>C67X00_DBG:ll_recv_msg() res=5000<br>C67X00_DBG:c67x00_ll_reset() - done recv_msg<br>C67X00_DBG:c67x00_of_probe() - Configuring SIEs<br>C67X00_DBG:ll_recv_msg() - calling wait_for_completion_timeout <br>
C67X00_DBG:ll_recv_msg() res=5000<br>����� : SIE 0 not set to host mode<br>����� : Cypress C67X00 Host Controller<br>Unable to handle kernel paging request for data at address 0x00000002<br>Faulting instruction address: 0xc0012654<br>
Oops: Kernel access of bad area, sig: 11 [#1]<br>PREEMPT Xilinx Virtex<br>Modules linked in:<br>NIP: c0012654 LR: c01c8ca0 CTR: c01fa0e4<br>REGS: c381db90 TRAP: 0300 Not tainted (2.6.29.4)<br>MSR: 00029030 <EE,ME,CE,IR,DR> CR: 35039055 XER: a000004b<br>
DEAR: 00000002, ESR: 00000000<br>TASK = c381a000[1] 'swapper' THREAD: c381c000<br>GPR00: 00000002 c381dc40 c381a000 00000002 00000001 00000000 fffffffe ffffffff <br>GPR08: 00000000 00000008 00000003 c380a0b1 35039059 ffffffff ffffffff ffffffff <br>
GPR16: ffffffff ffffffff ffffffff ffffffff ffffffff c398fee0 c035bdc4 c0360acc <br>GPR24: 00000000 00000000 c380a000 c03cac98 00000001 c385a84c 000000d0 c385a84c <br>NIP [c0012654] strlen+0x4/0x18<br>LR [c01c8ca0] kobject_get_path+0x34/0xe0<br>
Call Trace:<br>[c381dc40] [c01c91fc] add_uevent_var+0x74/0xf4 (unreliable)<br>[c381dc60] [c01fa190] dev_uevent+0xac/0x210<br>[c381dc80] [c01c94a8] kobject_uevent_env+0x22c/0x454<br>[c381dcd0] [c01fb164] device_add+0x39c/0x594<br>
[c381dd20] [c01fb418] device_create_vargs+0x8c/0xd0<br>[c381dd50] [c01fb49c] device_create+0x40/0x50<br>[c381dd80] [c0219fc0] usb_add_hcd+0x140/0x6d4<br>[c381ddb0] [c022daac] c67x00_hcd_probe+0x120/0x1f0<br>[c381ddd0] [c022c88c] c67x00_probe_sie+0xcc/0xe0<br>
[c381dde0] [c02f43a4] c67x00_of_probe+0x3fc/0x458<br>[c381de50] [c0258a88] of_platform_device_probe+0x5c/0x84<br>[c381de70] [c01fdb8c] driver_probe_device+0xbc/0x1f4<br>[c381de90] [c01fdd68] __driver_attach+0xa4/0xa8<br>[c381deb0] [c01fce78] bus_for_each_dev+0x5c/0x98<br>
[c381dee0] [c01fd990] driver_attach+0x24/0x34<br>[c381def0] [c01fd798] bus_add_driver+0x1d0/0x250<br>[c381df20] [c01fe0b4] driver_register+0x5c/0x150<br>[c381df40] [c0258950] of_register_driver+0x54/0x70<br>[c381df50] [c03aaa8c] c67x00_init+0x34/0x8c<br>
[c381df60] [c000236c] do_one_initcall+0x34/0x1a4<br>[c381dfd0] [c0393170] kernel_init+0x90/0xfc<br>[c381dff0] [c000fa24] kernel_thread+0x4c/0x68<br>Instruction dump:<br>4d820020 7ca903a6 38a3ffff 3884ffff 8c650001 2c830000 8c040001 7c601851 <br>
4d860020 4102ffec 4e800020 3883ffff <8c040001> 2c000000 4082fff8 7c632050 <br>---[ end trace f8500dd73d54b5fd ]---<br>Kernel panic - not syncing: Attempted to kill init!<br>Rebooting in 180 seconds..<br><br>-- ERROR 2 (with the board already on, just reprogramming fpga, kernel and booting again)-- <br>
<br>Generic platform RAM MTD, (c) 2004 Simtec Electronics<br>usbmon: debugfs is not available<br>C67X00_DBG:c67x00_of_probe() - Request memory region<br>C67X00_DBG:c67x00_of_probe() - Allocating data structs<br>C67X00_DBG:c67x00_of_probe() - Configuring c67x00 device<br>
C67X00_DBG:c67x00_of_probe() - Configure platform data based on the device-tree data<br>C67X00_DBG:c67x00_of_probe() - hpi.regstep: 2<br>C67X00_DBG:c67x00_of_probe() - SIE_config: 1<br>C67X00_DBG:c67x00_of_probe() - SIE_config: 21<br>
C67X00_DBG:c67x00_of_probe() - Low-level initizalization <br>C67X00_DBG:c67x00_ll_hpi_reg_init(): Reg:324 written=0x00 ; read: 0<br>C67X00_DBG:c67x00_ll_hpi_reg_init(): Reg:328 written=0x00 ; read: 0<br>C67X00_DBG:c67x00_of_probe() - Registering IRQ<br>
C67X00_DBG:c67x00_of_probe() - Trying to register IRQ:17 @ 17<br>C67X00_DBG:c67x00_of_probe() - Low-level reset<br>C67X00_DBG:c67x00_ll_reset() - Send mbox<br>C67X00_DBG:c67x00_ll_reset() - recv_msg<br>C67X00_DBG:ll_recv_msg() - calling wait_for_completion_timeout <br>
C67X00_DBG:ll_recv_msg() res=0<br>--> Here the processor halts when in call to WARN_ON(!res);<br><br>-- ERROR 3: gets stuck in the interrupt handler -- <br>�����;�L�=?� : Not all interrupts handled! status = 0x0148<br>
C67X00_DBG:c67x00_irq() - Handling IRQ number 328<br><br><div class="gmail_quote">2009/6/29 Peter Korsgaard <span dir="ltr"><<a href="mailto:jacmet@sunsite.dk" target="_blank">jacmet@sunsite.dk</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>>>>> "Jorge" == Jorge Sánchez de Nova <<a href="mailto:j.s.denova@gmail.com" target="_blank">j.s.denova@gmail.com</a>> writes:<br>
<br>
Jorge> Hi,<br>
<br>
Jorge> It doesn't work at all since it doesn't load anything. I have<br>
Jorge> looked at the driver and there is apparently no openfirmware<br>
Jorge> support for it, so maybe the dts info won't work without<br>
Jorge> it. Am I wrong? Does this means that the c67x00 needs OF<br>
Jorge> support to work in this configuration? How can I make it<br>
Jorge> otherwise?<br>
<br>
Yes, the c67x00 driver doesn't currently have any OF bindings. Either<br>
you can add it, or simply manually create the struct platform_device<br>
in your board file (or scan the DT in your board file and fill in the<br>
correct base address / interrupt number from it).<br>
<br>
Remember that arch/powerpc uses virtual interrupt numbers if you're<br>
going to fill in the platform_device by hand.<br>
<font color="#888888"><br>
--<br>
Bye, Peter Korsgaard<br>
</font></blockquote></div><br>