* Re: System Ace Driver Hangs.
From: Ameet Patil @ 2006-07-28 11:10 UTC (permalink / raw)
To: Raja Chidambaram; +Cc: linuxppc-embedded
In-Reply-To: <20060728110356.90311.qmail@web53614.mail.yahoo.com>
Hi Raja,
Did you update the xparameters_ml300.h or xparameters_ml403.h file
with the right defines for your specific board? If not, then you need to
update the file first. This first is automatically generated by the EDK
toolset. However, you might also choose to do it manually if you know
the right values. The driver would work with the right base-address.
cheers,
-Ameet
Raja Chidambaram wrote:
>
> Hi all,
>
> I got the system Ace driver compiled in to linux
> 2.6.12 but once the board boot's up , the console
> shows
>
> Data machine check in kernel mode.
> and continously runs the call trace.
>
> when i debugged the this problem on xsyace driver
> codebase the it hangs at function in & calls call
> trace
>
> >adapter.c
>
> --> if (XSysAce_Initialize(&SysAce, cfg->DeviceId)
> != XST_SUCCESS)
>
> when further debugged the function XSysAce_Initialize
> it call the funtion XSysAce_RegWrite16
>
> >xsyace.c
>
> -->#if (XPAR_XSYSACE_MEM_WIDTH == 16)
> XSysAce_RegWrite16(InstancePtr->BaseAddress +
> XSA_BMR_OFFSET,XSA_BMR_16BIT_MASK);
>
> in further debugging on the function
> XSysAce_RegWrite16
> shows
> >xsysace_l.c
>
> --> #if (XPAR_XSYSACE_MEM_WIDTH == 16)
> void XSysAce_RegWrite16(u32 Address, u16 Data)
> {
> u16 ConvertedData;
>
>
>
> /*
> * The ACE registers are little-endian always.
> This code takes the incoming
> * 16-bit and endian converts it, then writes it
> to the ACE register.
> */
> XIo_ToLittleEndian16(Data, &ConvertedData);
> XIo_Out(Address, ConvertedData); /***** the
> execution
> runs the call trace from this point ******/
>
> }
>
>
>
> I beleive their problem with macro value in
> > xparameters.h
>
> XPAR_SYSACE_COMPACTFLASH_BASEADDR 0x41800000
> can some one please explain how to specify the
> value for this macro mine is xccace-tq144i System ace
> or else is their any other problem to solve.please
> help me in this.thanks in advance.
>
> with regards
> k.raja
>
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
^ permalink raw reply
* Re: Host USB on MPC8247
From: Uros Borovsak @ 2006-07-28 11:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <44BF88A2.6080003@razvoj-verbic.si>
Hello,
Can you at least give me some idea how difficult would it be to patch
USB part of kernel from 2.6.13 to 2.6.10?
Are changes only in usb part of kernel, or are there also some changes
in other parts of kernel, that I would have to port?
Thanks,
Best regards
Uros
Uros Borovsak wrote:
> Hello,
>
> I'm looking for host USB driver for MPC8247. We are using MV kernel
> 2.6.10 and I'm wondering, if there is a driver for this specific kernel.
>
> I'm aware of cpm2usb project on sourceforge, but it is for kernel
> 2.6.13. How difficult would it be to patch only usb part of kernel from
> 2.6.10 to 2.6.13 so I could use that drivers. I only need suport for USB
> storage devices, so that driver is enough for me.
>
> Thanks,
>
> Best regards,
>
> Uros
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* writing CCSR_BAR register for relocation?
From: Parav Pandit @ 2006-07-28 11:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am newbie to MPC8555, PowerPC family and u-boot.
Please guide me.
1. How can I read/write registers from the u-boot
similar to md/mm command? Basically I want to
read/write CCSR_BAR from the u-boot.
2. How can I read/write CCSRBAR register value from my
assembly program?
mfspr.mtspr ??? what is the register name??
3. By changing the default value of 0xFF70:0000 to
0xE000:0000 is sufficient to relocate the 1MB block or
anything else is also required?
4. I look at the u-boot code for tqm85xx, 8555cds, and
8555ads series of boards and it does something with
TLB.
I don't understand why it modifies the TLB registers
whose purpose is only for the performance improvement?
Or we can use the TLB for something else also?
Regards,
Parav Pandit
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* writing CCSR_BAR register for relocation in MPC8555?
From: Parav Pandit @ 2006-07-28 11:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am newbie to MPC8555, PowerPC family and u-boot.
Please guide me.
1. How can I read/write registers from the u-boot
similar to md/mm command? Basically I want to
read/write CCSR_BAR from the u-boot.
2. How can I read/write CCSRBAR register value from my
assembly program?
mfspr.mtspr ??? what is the register name??
3. By changing the default value of 0xFF70:0000 to
0xE000:0000 is sufficient to relocate the 1MB block or
anything else is also required?
4. I look at the u-boot code for tqm85xx, 8555cds, and
8555ads series of boards and it does something with
TLB.
I don't understand why it modifies the TLB registers
whose purpose is only for the performance improvement?
Or we can use the TLB for something else also?
Regards,
Parav Pandit
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: writing CCSR_BAR register for relocation?
From: Parav Pandit @ 2006-07-28 12:01 UTC (permalink / raw)
To: Parav Pandit, linuxppc-embedded
In-Reply-To: <20060728112803.34466.qmail@web36610.mail.mud.yahoo.com>
I have read the MPC8555 RF.
section 4.3.1.1 says that CCSRBAR is points to itself.
Checked by the md command in u-boot.
it shows the same results, FF70:0000.
It shows the FF704600 also at that address for all the
addresses it shows the same content as address.
If this is the case, how come the u-boot works on
serial port? It should show some other value for the
configured devices such as serial port at least.
or somethign is missing on my side...
Regards,
Parav Pandit
--- Parav Pandit <paravpandit@yahoo.com> wrote:
> Hi,
>
> I am newbie to MPC8555, PowerPC family and u-boot.
> Please guide me.
>
> 1. How can I read/write registers from the u-boot
> similar to md/mm command? Basically I want to
> read/write CCSR_BAR from the u-boot.
>
> 2. How can I read/write CCSRBAR register value from
> my
> assembly program?
> mfspr.mtspr ??? what is the register name??
>
> 3. By changing the default value of 0xFF70:0000 to
> 0xE000:0000 is sufficient to relocate the 1MB block
> or
> anything else is also required?
>
> 4. I look at the u-boot code for tqm85xx, 8555cds,
> and
> 8555ads series of boards and it does something with
> TLB.
> I don't understand why it modifies the TLB registers
> whose purpose is only for the performance
> improvement?
> Or we can use the TLB for something else also?
>
> Regards,
> Parav Pandit
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Host USB on MPC8247
From: Uros Borovsak @ 2006-07-28 12:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <44BF88A2.6080003@razvoj-verbic.si>
Hello,
Can you at least give me some idea how difficult would it be to patch
USB part of kernel from 2.6.13 to 2.6.10?
Are changes only in usb part of kernel, or are there also some changes
in other parts of kernel, that I would have to port?
Thanks,
Best regards
Uros
Uros Borovsak wrote:
> Hello,
>
> I'm looking for host USB driver for MPC8247. We are using MV kernel
> 2.6.10 and I'm wondering, if there is a driver for this specific kernel.
>
> I'm aware of cpm2usb project on sourceforge, but it is for kernel
> 2.6.13. How difficult would it be to patch only usb part of kernel from
> 2.6.10 to 2.6.13 so I could use that drivers. I only need suport for USB
> storage devices, so that driver is enough for me.
>
> Thanks,
>
> Best regards,
>
> Uros
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: bennett78 @ 2006-07-28 14:02 UTC (permalink / raw)
To: dhlii; +Cc: Clint Thomas, linuxppc-embedded
In-Reply-To: <44C9C4E4.2060206@dlasys.net>
[-- Attachment #1: Type: text/plain, Size: 3213 bytes --]
David H. Lynch Jr. wrote:
> Clint Thomas wrote:
>
>> Hey guys,
>>
>> I have gone through the Linuxppc embedded and dev lists for
>> information related to what I am trying to do, but was unable to find
>> exactly what i'm looking for.
>>
>> Basically, the system I want linux running on does not require the
>> initialization of hardware that U-boot provides, or at least it does
>> not need it to boot the linux kernel. I want to load an uncompressed
>> linux kernel into memory and start the execution of the kernel,
>> without using any kind of bootloader. Is this possible? Or does linux
>> need some kind of firmware or other software to tell it to start
>> executing? Thanks for any info you might have.
>
>
> You system powers on. It starts executing whatever is at the reset
> vector, Something has to get you from the ppc powering up and going to
> never never land, to starting to execute Linux.
> The steps to get from Power on to booting Linux may not be that
> complicated, Much of what needs to be done can likely be included as
> part of the code for your board in arch/ppc/boot/simple.
> But something still has to be done.
>
> In my instance I am dealing with a Xilinx V4 (not an ML403). A
> small "monitor" program is automatically loaded as part of the FPGA
> .bit image. On power on it starts executing.
Curious, how long does the V4 take to load up it's brain? (using a
serial EEprom?)
> It sets up the CPU, cache, and very minimal hardware
> configuration, and then loads Linux out of flash and executes it.
>
> Linux does not have to have alot setup to boot. But something has
> to to some minimal initial setup, get Linux into the memory of your
> system, and jump to it.
>
>>
>> Clinton Thomas
>> cthomas@soneticom.com
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>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 dhlii@dlasys.net 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
>
Frank Bennett
*/Technical Contractor/*
/Triad Systems Engineering
200 West Mountain Avenue, Suite 103C
Ft. Collins, CO 80521
/http://www.traidsyseng.com <http://www.triadsyseng.com>
frank.bennett@triadsyseng.com <mailto:frank.bennett@triadsyseng.com>/
/office: 970-493-7586
cell: 970-402-9269
"I think there's a world market for about five computers."
-- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943
[-- Attachment #2: Type: text/html, Size: 5332 bytes --]
^ permalink raw reply
* Re: Where to store the Linux kernel.
From: Frank D Lombardo @ 2006-07-28 14:48 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F35E07B168493E31407D7C2B2580@phx.gbl>
Ming,
I have the XPS generated bootloader in bram. The bram is located at the
reset vector. The XPS bootloader loads U-Boot s-records from linear
flash into ram and then executes it. U-Boot can then handle booting the
Linux Kernel image (uImage, not zImage.elf) from linear flash.
XPS can program the linear flash for you. In XPS 8.1 the menu option is
"Device Configuration | Program Flash Memory". I use this to program the
U-Boot s-records and the Kernel uImage to linear flash.
I have not tried to put both the download.bit and Kernel uImage into
platform flash, so I can't comment on that.
Frank
Ming Liu wrote:
> Dear Frank,
>
>> I am using an ML403 in a similar way. I have the download.bit file
>> stored in platform flash. U-Boot, the Linux Kernel and initrd are stored
>> in the linear flash.
> That's just what I want! Can you say something in detail on how to put
> the bootloader and the kernel image in the linear flash in XPS? I know
> that XPS can generate a bootloader automatically. So can we use that
> one instead of U-boot?
> By the way, can we put both the download.bit and the Linux image
> zImage.elf in the platform flash and boot the system from here? If
> yes, then in the real product, I need only one platform flash to store
> my design then.
> Thanks for your telling.
>
> Regards
> Ming
>
> _________________________________________________________________
> 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>
^ permalink raw reply
* USB flashdrive on Motorola MPC5200 (IceCube) board, linux kernel 2.4.25 (DENX drop)
From: Furxhi, Orges @ 2006-07-28 14:53 UTC (permalink / raw)
To: 'Igor Luri'; +Cc: linuxppc-embedded
Igor, and anyone else who can help,
About 1 month ago you replied to one of my messages on the board. I was
trying to get the USB working as a mass storage device, mainly to be used
for file transfer, but I was having no success so I stopped working on that
and got on to other parts of the project. Now I got back on it.
I have a LITE5200 Version 2.0 board and I have loaded the latest DENX drop
of the 2.4 kernel on it. When I plug in the usb flash drive I get the
following message:
Usb.c: USB device not accepting new address=4 (error=-110)
Usb.c: USB device not accepting new address=5 (error=-110)
I must be doing something wrong, and I do not know what it is.
You said that you had the same board and kernel and that your USB as mass
storage was working. Could you please send me your kernel's .config file so
that I can compare it with mine?
Thanks,
Orges
-----Original Message-----
From: Igor Luri [mailto:iluri@fagorautomation.es]
Sent: Wednesday, June 14, 2006 8:57 AM
To: Furxhi, Orges
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: USB flashdrive on Motorola MPC5200 (IceCube) board, linux
kernel 2.4.20
It is posible that your kernel uses old USB code. We also have an
Icecube board, the same board a yours, with linux 2.4.25 version from
DENX and USB works well.
You can try with this kernel:
ftp://ftp.denx.de/pub/linux/linuxppc_2_4_devel-2006-04-06-1735.tar.bz2
Hope this helps.
Furxhi, Orges wrote:
>Thank you for your help.
>
>I am using a Memorex travel drive 2.0 (512 MB), and I also have a
>Intelligent Stick 2.0 from GE.
>When I plug in the Memorex stick the following appears on the terminal :
> # hub.c: new USB device builtin-1, assigned address 2
> usb.c: USB device not accepting new address=2 (error=-110)
> hub.c: new USB device builtin-1, assigned address 3
> usb.c: USB device not accepting new address=3 (error=-110)
>
>When I plug in the GE stick nothing shows on the terminal, but when I
remove
>it the following message comes up:
> # hub.c: connect-debounce failed, port 1 disabled
>
>Both the USB flash drives work on my Dell PC with RedHat 9.0 (2.4.20
>kernel).
>
>Orges
>
>
>
>-----Original Message-----
>From: Igor Luri [mailto:iluri@fagorautomation.es]
>Sent: Wednesday, June 14, 2006 3:07 AM
>To: Furxhi, Orges
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: USB flashdrive on Motorola MPC5200 (IceCube) board, linux
>kernel 2.4.20
>
>What kind of USB flash drive are you using? Linux doesn't detect your
>device.
>
>When you plug/unplug a USB device you have to get something like this:
>
> hub.c: new USB device 0-1, assigned address 2
> scsi0 : SCSI emulation for USB Mass Storage devices
> Vendor: Model: USB DISK Pro Rev: 1.00
> Type: Direct-Access ANSI SCSI revision: 02
> Attached scsi removable disk sda at scsi0, channel 0, id 0,
> lun 0
> SCSI device sda: 240640 512-byte hdwr sectors (123 MB)
> sda: Write Protect is off
> sda: sda1
>
> usb.c: USB disconnect on device 0-1 address 2
>
>
>Are you sure that this device is supported in your Linux configuration?
>
>
>
>Furxhi, Orges wrote:
>
>
>
>>Hi all,
>>
>>I have been trying for days now to get my usb flashdrive to work on my
>>Motorola MPC5200 (IceCube) board running on the 2.4.20 linux kernel. I
>>have followed the instruction in this Flash Memory HOWTO article
>>(http://www.tldp.org/HOWTO/Flash-Memory-HOWTO/index.html), but I have
>>had no success.
>>
>>When I mount the usbfs filesystem (mount -t usbfs none /proc/bus/usb/)
>>the following 3 items are created in the /proc/bus/usb/ directory:
>>
>>dr-xr-xr-x 1 root root 0 Jan 1 00:12 001
>>
>>-r--r--r-- 1 root root 0 Jan 1 00:12 devices
>>
>>-r--r--r-- 1 root root 0 Jan 1 00:12 drivers
>>
>># cat devices shows:
>>
>>T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
>>
>>B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
>>
>>D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
>>
>>P: Vendor=0000 ProdID=0000 Rev= 0.00
>>
>>S: Product=USB OHCI Root Hub
>>
>>S: SerialNumber=f0001000
>>
>>C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
>>
>>I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
>>
>>E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
>>
>># cat drivers shows
>>
>>usbdevfs
>>
>>hub
>>
>>usb-storage
>>
>>In the this Flash Memory-HOWTO it is mentioned that the usb-storage-x
>>directory will be created in the /proc/scsi/ directory, but I do not
>>see it on my system. Also the contents of /proc/scsi/scsi are
>>"Attached devices: none".
>>
>>Following are my boot up messages:
>>
>>U-Boot 1.1.4 (Mar 21 2006 - 15:07:57)
>>
>>CPU: MPC5200 v1.2 at 462 MHz
>>
>>Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
>>
>>Board: Motorola MPC5200 (IceCube)
>>
>>I2C: 85 kHz, ready
>>
>>DRAM: 64 MB
>>
>>FLASH: 8 MB
>>
>>In: serial
>>
>>Out: serial
>>
>>Err: serial
>>
>>Net: FEC ETHERNET
>>
>>Type "run flash_nfs" to mount root filesystem over NFS
>>
>>Hit any key to stop autoboot: 0
>>
>>## Booting image at ff900000 ...
>>
>>Image Name: Linux-2.4.20_mvl31-lite5200
>>
>>Created: 2006-06-13 21:40:05 UTC
>>
>>Image Type: PowerPC Linux Kernel Image (gzip compressed)
>>
>>Data Size: 989480 Bytes = 966.3 kB
>>
>>Load Address: 00000000
>>
>>Entry Point: 00000000
>>
>>Verifying Checksum ... OK
>>
>>Uncompressing Kernel Image ... OK
>>
>>Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
>>
>>Linux version 2.4.20_mvl31-lite5200 (ofurxhi@mdc58503) (gcc version
>>3.3.1 (Monta
>>
>>Vista 3.3.1-7.0.13.0500039 2005-01-12)) #11 Tue Jun 13 16:32:09 CDT 2006
>>
>>On node 0 totalpages: 16384
>>
>>zone(0): 16384 pages.
>>
>>zone(1): 0 pages.
>>
>>zone(2): 0 pages.
>>
>>Kernel command line: root=/dev/mtdblock2 rw rootfstype=jffs2
>>ip=192.168.0.7:192.
>>
>>168.0.2:192.168.0.2:255.255.255.0:cpua::off
>>
>>frequencies: cpu=461995100, bus=131998608, ipb=65999304, pci=32999652
>>
>>Calibrating delay loop... 307.20 BogoMIPS
>>
>>Memory: 62460k available (1540k kernel code, 524k data, 240k init, 0k
>>highmem)
>>
>>Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
>>
>>Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
>>
>>Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
>>
>>Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
>>
>>Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
>>
>>POSIX conformance testing by UNIFIX
>>
>>PCI: Probing PCI hardware
>>
>>PCI: Cannot allocate resource region 1 of device 00:00.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:01.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:02.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:03.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:04.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:05.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:06.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:07.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:08.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:09.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:0a.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:0b.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:0c.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:0d.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:0e.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:0f.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:10.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:11.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:12.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:13.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:14.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:15.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:16.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:17.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:18.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:19.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:1a.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:1b.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:1c.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:1d.0
>>
>>PCI: Cannot allocate resource region 1 of device 00:1e.0
>>
>>Linux NET4.0 for Linux 2.4
>>
>>Based upon Swansea University Computer Society NET3.039
>>
>>Initializing RT netlink socket
>>
>>LSP Revision 52
>>
>>ikconfig 0.5 with /proc/ikconfig
>>
>>Starting kswapd
>>
>>Disabling the Out Of Memory Killer
>>
>>Journalled Block Device driver loaded
>>
>>devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
>>
>>devfs: boot_options: 0x1
>>
>>JFFS version 1.0, (C) 1999, 2000 Axis Communications AB
>>
>>JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis
>>Communications
>>
>>AB.
>>
>>pty: 256 Unix98 ptys configured
>>
>>RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
>>
>>loop: loaded (max 8 devices)
>>
>>Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
>>
>>SCSI subsystem driver Revision: 1.00
>>
>>kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
>>
>>kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
>>
>>NO QRY response
>>
>>cfi_cmdset_0001: Erase suspend on write enabled
>>
>>Using buffer write method
>>
>>Icecube flash bank 0: Using static image partition definition
>>
>>Creating 3 MTD partitions on "Icecube Bank 0":
>>
>>0x00000000-0x00100000 : "u-boot"
>>
>>0x00100000-0x00200000 : "kernel"
>>
>>0x00200000-0x00800000 : "jffs2"
>>
>>usb.c: registered new driver usbdevfs
>>
>>usb.c: registered new driver hub
>>
>>usb-ohci.c: USB OHCI at membase 0xf0001000, IRQ 44
>>
>>usb.c: new USB bus registered, assigned bus number 1
>>
>>Product: USB OHCI Root Hub
>>
>>SerialNumber: f0001000
>>
>>hub.c: USB hub found
>>
>>hub.c: 2 ports detected
>>
>>Initializing USB Mass Storage driver...
>>
>>usb.c: registered new driver usb-storage
>>
>>USB Mass Storage support registered.
>>
>>eth0: Phy @ 0x0, type LXT971 (0x001378e2)
>>
>>NET4: Linux TCP/IP 1.0 for NET4.0
>>
>>IP Protocols: ICMP, UDP, TCP, IGMP
>>
>>IP: routing cache hash table of 512 buckets, 4Kbytes
>>
>>TCP: Hash tables configured (established 4096 bind 8192)
>>
>>eth0: config: auto-negotiation off, 100HDX, 10HDX.
>>
>>IP-Config: Complete:
>>
>>device=eth0, addr=192.168.0.7, mask=255.255.255.0, gw=192.168.0.2,
>>
>>host=cpua, domain=, nis-domain=(none),
>>
>>bootserver=192.168.0.2, rootserver=192.168.0.2, rootpath=
>>
>>NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
>>
>>Empty flash at 0x0000fffc ends at 0x00010000
>>
>>CLEANMARKER node found at 0x00010000, not first node in block (0x00000000)
>>
>>Empty flash at 0x0002fffc ends at 0x00030000
>>
>>CLEANMARKER node found at 0x00030000, not first node in block (0x00020000)
>>
>>Empty flash at 0x0004fffc ends at 0x00050000
>>
>>CLEANMARKER node found at 0x00050000, not first node in block (0x00040000)
>>
>>Empty flash at 0x0006fffc ends at 0x00070000
>>
>>CLEANMARKER node found at 0x00070000, not first node in block (0x00060000)
>>
>>Empty flash at 0x0008fffc ends at 0x00090000
>>
>>CLEANMARKER node found at 0x00090000, not first node in block (0x00080000)
>>
>>Empty flash at 0x000afffc ends at 0x000b0000
>>
>>CLEANMARKER node found at 0x000b0000, not first node in block (0x000a0000)
>>
>>Empty flash at 0x000cfffc ends at 0x000d0000
>>
>>CLEANMARKER node found at 0x000d0000, not first node in block (0x000c0000)
>>
>>Empty flash at 0x000efffc ends at 0x000f0000
>>
>>CLEANMARKER node found at 0x000f0000, not first node in block (0x000e0000)
>>
>>Empty flash at 0x0010fffc ends at 0x00110000
>>
>>CLEANMARKER node found at 0x00110000, not first node in block (0x00100000)
>>
>>Empty flash at 0x0012fffc ends at 0x00130000
>>
>>CLEANMARKER node found at 0x00130000, not first node in block (0x00120000)
>>
>>Empty flash at 0x0014fffc ends at 0x00150000
>>
>>CLEANMARKER node found at 0x00150000, not first node in block (0x00140000)
>>
>>Empty flash at 0x0016fffc ends at 0x00170000
>>
>>CLEANMARKER node found at 0x00170000, not first node in block (0x00160000)
>>
>>Empty flash at 0x0018fffc ends at 0x00190000
>>
>>CLEANMARKER node found at 0x00190000, not first node in block (0x00180000)
>>
>>Empty flash at 0x001afffc ends at 0x001b0000
>>
>>CLEANMARKER node found at 0x001b0000, not first node in block (0x001a0000)
>>
>>Empty flash at 0x001cfffc ends at 0x001d0000
>>
>>CLEANMARKER node found at 0x001d0000, not first node in block (0x001c0000)
>>
>>Empty flash at 0x001efffc ends at 0x001f0000
>>
>>CLEANMARKER node found at 0x001f0000, not first node in block (0x001e0000)
>>
>>Empty flash at 0x0020fffc ends at 0x00210000
>>
>>CLEANMARKER node found at 0x00210000, not first node in block (0x00200000)
>>
>>Empty flash at 0x0022fffc ends at 0x00230000
>>
>>CLEANMARKER node found at 0x00230000, not first node in block (0x00220000)
>>
>>Empty flash at 0x0024fffc ends at 0x00250000
>>
>>CLEANMARKER node found at 0x00250000, not first node in block (0x00240000)
>>
>>Empty flash at 0x0026fffc ends at 0x00270000
>>
>>CLEANMARKER node found at 0x00270000, not first node in block (0x00260000)
>>
>>VFS: Mounted root (jffs2 filesystem).
>>
>>Mounted devfs on /dev
>>
>>Freeing unused kernel memory: 240k init
>>
>>serial console detected. Disabling virtual terminals.
>>
>>init started: BusyBox v0.60.3 (2004.01.09-22:53+0000) multi-call binary
>>
>>Initializing iocspi
>>
>>Warning: loading /lib/modules/iocspim.o will taint the kernel: no license
>>
>>See http://www.tux.org/lkml/#export-tainted for information about
>>tainted modu
>>
>>les
>>
>>iocspi: release_20060418
>>
>>iocspi: major 254.
>>
>>Module iocspim loaded, with warnings
>>
>>Initializing canspi
>>
>>Warning: loading /lib/modules/canspim.o will taint the kernel: no license
>>
>>See http://www.tux.org/lkml/#export-tainted for information about
>>tainted modu
>>
>>les
>>
>>canspi: init_module()
>>
>>canspi: init_module(): sema_init
>>
>>canspi: init_module(): register_chrdev
>>
>>canspi: major 253.
>>
>>canspi: micro_config()
>>
>>canspi: micro_config: PSC request_irq failed (0)
>>
>>canspi: micro_config psc=f0002400 cdm=f0000200 gpio=f0000b00
>>portcfg=10051004
>>
>>Module canspim loaded, with warnings
>>
>>Initializing iocdrv
>>
>>Warning: loading /lib/modules/iocdrvm.o will taint the kernel: no license
>>
>>See http://www.tux.org/lkml/#export-tainted for information about
>>tainted modu
>>
>>les
>>
>>iocdrv: release_20060502
>>
>>iocdrv: major 252.
>>
>>Module iocdrvm loaded, with warnings
>>
>>System initialized
>>
>>MontaVista(R) Linux(R) Professional Edition 3.1
>>
>>cpua login:
>>
>>Any help would be highly appreciated.
>>
>>Thank you,
>>
>>Orges Furxhi
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>>
^ permalink raw reply
* scheduler death with 2.6.17 on JS21 blades when running stress -c 32750 ...
From: Sven Luther @ 2006-07-28 16:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060728160943.GA12080@powerlinux.fr>
Hi, ...
It was reported to me that, when using the debian 2.6.17 kernel on a JS21
blade (with 1 or 2 970MP cpus), and running stress -c 32750 on it, the blade
dies with some fork ressource problems (don't have the exact message, but it
loops all over the screen), and the blade is completely hosed, and even not
resetable (you have to off/on it).
The kern.log after reboot shows :
Jul 25 11:50:24 debian3 kernel: BUG: soft lockup detected on CPU#0!
Jul 25 11:50:24 debian3 kernel: NIP: C0000000002AE334 LR: C0000000002AE2E0 CTR: C00000000000D7AC
Jul 25 11:50:24 debian3 kernel: REGS: c0000000003479b0 TRAP: 0901 Not tainted (2.6.15-1-powerpc64)
Jul 25 11:50:24 debian3 kernel: MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000082 XER: 00000010
Jul 25 11:50:24 debian3 kernel: TASK = c00000000037cea0[0] 'swapper' THREAD: c000000000344000 CPU: 0
Jul 25 11:50:24 debian3 kernel: GPR00: 8000000000009032 C000000000347C30 C00000000042BCB8 C00000009EC10980
Jul 25 11:50:24 debian3 kernel: GPR04: C00000000037D1A0 0000000000000002 0000000024000082 C000000000022034
Jul 25 11:50:24 debian3 kernel: GPR08: C00000000033F860 C000000004E93760 0000000000000000 0000000004B53F00
Jul 25 11:50:24 debian3 kernel: GPR12: FFFFFFFFFFFFFFFF C000000000366C00
Jul 25 11:50:24 debian3 kernel: NIP [C0000000002AE334] .schedule+0xcac/0xdac
Jul 25 11:50:24 debian3 kernel: LR [C0000000002AE2E0] .schedule+0xc58/0xdac
Jul 25 11:50:24 debian3 kernel: Call Trace:
Jul 25 11:50:24 debian3 kernel: [C000000000347C30] [C0000000002AE2E0] .schedule+0xc58/0xdac (unreliable)
Jul 25 11:50:24 debian3 kernel: [C000000000347D40] [C00000000003CD4C] .pseries_dedicated_idle+0x1d8/0x1e0
Jul 25 11:50:24 debian3 kernel: [C000000000347DF0] [C00000000001C5C4] .cpu_idle+0x40/0x54
Jul 25 11:50:24 debian3 kernel: [C000000000347E60] [C0000000000091F4] .rest_init+0x44/0x5c
Jul 25 11:50:24 debian3 kernel: [C000000000347EE0] [C00000000030D868] .start_kernel+0x2e0/0x308
Jul 25 11:50:24 debian3 kernel: [C000000000347F90] [C0000000000084F4] .hmt_init+0x0/0xc
Jul 25 11:50:24 debian3 kernel: Instruction dump:
Jul 25 11:50:24 debian3 kernel: 7d285a14 e8690060 f9490060 60000000 60000000 60000000 ebbf0018 7c2004ac
Jul 25 11:50:24 debian3 kernel: 7d48592e 7c0000a6 60008000 7c010164 <2fa30000> 419e0030 3803004c 7c0006ac
(Mmm, the log is from a 2.6.15 kernel, which was in debian testing, but a
similar problem happens with the 2.6.17 debian kernel, which as far as 64bit
powerpc is concerned is mostly mainline).
Did anyone alredy encounter this problem and has any hint on how to fix it ? I
cannot reproduce it on my powerbook, nor on a single G5 powermac, nor on
power5 machines (p505 and a quad cpu openpower), and i don't have hand-on
access to JS21 blades myself.
Friendly,
Sven Luther
^ permalink raw reply
* using /dev/mem to talk to peripherals on VIIP system
From: scott @ 2006-07-28 17:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
Hello again,
well i didn't get any responses at all to my last post so I thought i'd try this again.
I have kernel 2.4.26 installed on a Xilinx XUP board and everything works well except I can't seem to communicate with peripherals on the OPB or PLB bus through devfs. devfs is on and mounted and everything, and I'm able open a file handle to it w/ the following code:
int main (int argc, char *argv[]) {
int fd;
int *ptr;
fd = open("/dev/mem", O_RDWR);
if(fd == -1) {
printf("Err: cannot open /dev/mem\n");
return -1;
}
ptr = MAP_FAILED; // Initialize to bad value
ptr = (int *) mmap(0, 256, PROT_READ|PROT_WRITE, MAP_SHARED, fd, USER_LOGIC_BASEADDR);
if(ptr==MAP_FAILED) {
printf("Err: cannot access address!\n");
return -1;
}
*ptr = 0xA0000000;
...
mmap also seems to work, and returns a virtual address that is supposed to point to the location in physical memory at USER_LOGIC_BASEADDR. when I try to use ptr, however, I either get
bus error
or
do_wp_page: bogus page at address 3001a000 (page 0xc2c4c004)
VM: killing process led_test.o
depending on whether I use MAP_SHARED or MAP_PRIVATE.
These errors occur if I try to access any device on either PLB or OPB - even the OPB UART (which i KNOW is working). This technique DOES work, however, for address ranges in RAM. This indicates to me that it's some sort of higher level memory management problem w/ linuxppc such that it doesn't realize these address ranges are valid. I assume this is a function of the BSP that gets generated in EDK? Anybody have any idea how I can tell linux to let me use these addresses? Any other thoughts?
If I'm being too vague or something please let me know and I'll resolve it immediately...
Thanks much, --scott
Other details:
linuxppc-2.4.26
busybox 1.1.0
powerpc-405-linux-gnu-gcc 3.4.1
[-- Attachment #2: Type: text/html, Size: 2335 bytes --]
^ permalink raw reply
* Re: using /dev/mem to talk to peripherals on VIIP system
From: Dan Malek @ 2006-07-28 17:51 UTC (permalink / raw)
To: scott; +Cc: linuxppc-embedded
In-Reply-To: <20060728173519.55388.qmail@web33312.mail.mud.yahoo.com>
On Jul 28, 2006, at 1:35 PM, scott wrote:
> ptr = MAP_FAILED; // Initialize to bad value
> ptr = (int *) mmap(0, 256, PROT_READ|PROT_WRITE, MAP_SHARED, fd,
> USER_LOGIC_BASEADDR);
Well, this isn't going to detect an error, since the error code
is returned instead of an address.
>
> if(ptr==MAP_FAILED) {
if ((int)ptr == -1) {
> printf("Err: cannot access address!\n");
> return -1;
> }
>
> .... Any other thoughts?
Your mmap is failing because the size is not modulo PAGE_SIZE.
-- Dan
^ permalink raw reply
* Re: Why the "opd" section?
From: Linas Vepstas @ 2006-07-28 18:19 UTC (permalink / raw)
To: Alan Modra; +Cc: linuxppc-dev
In-Reply-To: <20060725140634.GH6872@bubble.grove.modra.org>
On Tue, Jul 25, 2006 at 11:36:34PM +0930, Alan Modra wrote:
> >
> > So, why is it only in the 64-bit ELF? Is it just because it's a newer
> > idea?
>
> The idea isn't exactly new. It's more the case that the powerpc32 ABI
> is so old.
The basic idea/structure of the TOC was fixed in 1988, when the
linkage conventions for the pre-powerpc POWER were being speced.
I have no idea why the ppc32 ABI wouldn't have used this.
> > mflr 0
> > std 0,16(1)
> > stdu 1,-112(1)
> > bl addone
> > nop
> > bl addone
> > nop
> > addi 1,1,112
> > ld 0,16(1)
> > mtlr 0
> > blr
> >
> Yes, you're right. It does look to be branching directly to the opd
> entry at the assembly level. It of course won't do that because
> powerpc64-ld is clever enough to realise that doing so would never make
> any sense. Instead, ld does the OPD lookup and modifies the "bl" insns
> to go directly to the function's code entry if the TOC vallue of caller
> and callee is identical, or to go via a linker generated stub if they
> are different.
I beleive the no-op provides the space for the needed extra insns when
the linker goes to fix this up. If you disassemble the exectuable for
the case where addone is in some shared library, you'd see the bl replaced
by bl .glink (I think its called .glink, I don't remember), with the
.glink code fiddling with loading the right r2 TOC pointer as needed.
I've forgotten the details.
I vaguely remember yet another interesting trick, where the linker inserts
some dynamic-link stubs -- and so, when the subroutine is called for the
very first time ever, some additional linkage is done by the stub. I
have no idea if the current gcc/glibc do this.
--linas
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Segher Boessenkool @ 2006-07-28 18:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154062599.21801.40.camel@localhost.localdomain>
>> The RTAS patch skips the intel-centric MSI layer and uses
>> pci_enable/disable_msi() calls directly. It does not correctly
>> handle
>> multi-vector MSI either.
>
> Multi-vector MSIs aren't handled by the linux API anyway it seems (the
> doc says pci_enable_msi() only ever enables one MSI) so that's fine if
> you don't handle them :) The word on the street is that multivector
> MSIs
> aren't useful, MSI-X are.
pci_enable_msi() should always enable exactly one or zero MSIs. Maybe
Jake's patch doesn't follow this rule, and that is what he alluded to?
Segher
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Jake Moilanen @ 2006-07-28 18:42 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <802085A1-AA37-4787-A2D6-B619C6BE7AB4@kernel.crashing.org>
On Fri, 2006-07-28 at 20:43 +0200, Segher Boessenkool wrote:
> >> The RTAS patch skips the intel-centric MSI layer and uses
> >> pci_enable/disable_msi() calls directly. It does not correctly
> >> handle
> >> multi-vector MSI either.
> >
> > Multi-vector MSIs aren't handled by the linux API anyway it seems (the
> > doc says pci_enable_msi() only ever enables one MSI) so that's fine if
> > you don't handle them :) The word on the street is that multivector
> > MSIs
> > aren't useful, MSI-X are.
>
> pci_enable_msi() should always enable exactly one or zero MSIs. Maybe
> Jake's patch doesn't follow this rule, and that is what he alluded to?
Sorry, I was less-than-clear. I was going to use this same framework
for MSI-X, and I was saying that it is not being correctly handled at
this point.
Jake
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Segher Boessenkool @ 2006-07-28 18:53 UTC (permalink / raw)
To: Jake Moilanen; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1154112142.29826.297.camel@goblue>
> Sorry, I was less-than-clear. I was going to use this same framework
> for MSI-X, and I was saying that it is not being correctly handled at
> this point.
Well it's _correct_ -- pci_enable_msix() always returns failure, that's
fine from a correctness perspective (although suboptimal from a
performance
or functionality perspective, heh).
Segher
^ permalink raw reply
* Re: using /dev/mem to talk to peripherals on VIIP system
From: scott @ 2006-07-28 19:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <7348068C-0799-4FE1-A149-DE8043ABB81E@embeddedalley.com>
[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]
Hi Dan, thanks for your quick response! I was using a reference to mmap from this page:
http://www.opengroup.org/onlinepubs/000095399/functions/mmap.html
which states that mmap will return MAP_FAILED if there is an error and the error will be located in errno. please correct me if this is wrong. As such i don't believe that the map is failing.
i did in any case make the size modulo with PAGE_SIZE (=4096) as found in asm-ppc/page.h which unfortunately did not fix the problem. just for the heck of it I also tried every size from 1 up to 65536...
It's worth noting that I also tried treating /dev/mem as a file (as it was intended) by using functions lseek, read, and write. read and write returned a value of zero upon completion, indicating that no bytes were read/written. I get the feeling that file I/O functions failing on /dev/mem indicates something important, but I'm not sure what. especially since /dev/mem operations DO work on other parts of physical memory (such as RAM).
--scott
----- Original Message ----
From: Dan Malek <dan@embeddedalley.com>
To: scott <scotto2hot-green@yahoo.com>
Cc: linuxppc-embedded@ozlabs.org
Sent: Friday, July 28, 2006 11:51:03 AM
Subject: Re: using /dev/mem to talk to peripherals on VIIP system
On Jul 28, 2006, at 1:35 PM, scott wrote:
> ptr = MAP_FAILED; // Initialize to bad value
> ptr = (int *) mmap(0, 256, PROT_READ|PROT_WRITE, MAP_SHARED, fd,
> USER_LOGIC_BASEADDR);
Well, this isn't going to detect an error, since the error code
is returned instead of an address.
>
> if(ptr==MAP_FAILED) {
if ((int)ptr == -1) {
> printf("Err: cannot access address!\n");
> return -1;
> }
>
> .... Any other thoughts?
Your mmap is failing because the size is not modulo PAGE_SIZE.
-- Dan
[-- Attachment #2: Type: text/html, Size: 2606 bytes --]
^ permalink raw reply
* Re: USB flashdrive on Motorola MPC5200 (IceCube) board, linux kernel 2.4.25 (DENX drop)
From: Wolfgang Denk @ 2006-07-28 20:07 UTC (permalink / raw)
To: Furxhi, Orges; +Cc: linuxppc-embedded
In-Reply-To: <162B449665D6D643AD9E1D50FC6F4B14042F1C93@mdcexc05.na.ops.local>
Dear Orges,
in message <162B449665D6D643AD9E1D50FC6F4B14042F1C93@mdcexc05.na.ops.local> you wrote:
>
> I have a LITE5200 Version 2.0 board and I have loaded the latest DENX drop
> of the 2.4 kernel on it. When I plug in the usb flash drive I get the
> following message:
>
> Usb.c: USB device not accepting new address=4 (error=-110)
> Usb.c: USB device not accepting new address=5 (error=-110)
>
> I must be doing something wrong, and I do not know what it is.
Are you just trying one specific type opf USB device, or does this
happen with several 5 or more) different devices?
> You said that you had the same board and kernel and that your USB as mass
> storage was working. Could you please send me your kernel's .config file so
> that I can compare it with mine?
You can just use the default configuration as provided with the
kernel tree. Make sure to use a current kernel (top of tree in git
repo).
And keep in mind that many USB devices are simply not strctly
standard conforming. Some will work, others won't.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The biggest difference between time and space is that you can't reuse
time. - Merrick Furst
^ permalink raw reply
* RE: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Furxhi, Orges @ 2006-07-28 21:09 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]
-----Original Message-----
From: Furxhi, Orges
Sent: Friday, July 28, 2006 4:03 PM
To: 'Wolfgang Denk'
Subject: RE: USB flashdrive on Motorola MPC5200 (IceCube) board, linux
kernel 2.4.25 (DENX drop)
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Friday, July 28, 2006 3:08 PM
To: Furxhi, Orges
Cc: 'Igor Luri'; linuxppc-embedded@ozlabs.org
Subject: Re: USB flashdrive on Motorola MPC5200 (IceCube) board, linux
kernel 2.4.25 (DENX drop)
Dear Orges,
in message <162B449665D6D643AD9E1D50FC6F4B14042F1C93@mdcexc05.na.ops.local>
you wrote:
>
> I have a LITE5200 Version 2.0 board and I have loaded the latest DENX drop
> of the 2.4 kernel on it. When I plug in the usb flash drive I get the
> following message:
>
> Usb.c: USB device not accepting new address=4 (error=-110)
> Usb.c: USB device not accepting new address=5 (error=-110)
>
> I must be doing something wrong, and I do not know what it is.
Are you just trying one specific type opf USB device, or does this
happen with several 5 or more) different devices?
We tried 6 different USB flash drives:
GE intelligent stick 2.0 (256MB)
PNY
SanDisk Cruzer Micro (256MB)
Version G (512MB)
Memorex traveldrive mini (512MB)
Unknown brand (64MB)
Are there any flashdrives that are known to always work?
> You said that you had the same board and kernel and that your USB as mass
> storage was working. Could you please send me your kernel's .config file
so
> that I can compare it with mine?
You can just use the default configuration as provided with the
kernel tree. Make sure to use a current kernel (top of tree in git
repo).
We have the latest 2.4 drop from the git repo. Which of the defconfig files
should we use? None of them had usb storage enabled (icecube board).
Thanks a lot,
Orges
And keep in mind that many USB devices are simply not strctly
standard conforming. Some will work, others won't.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The biggest difference between time and space is that you can't reuse
time. - Merrick Furst
[-- Attachment #2: Type: application/ms-tnef, Size: 3617 bytes --]
^ permalink raw reply
* Re: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Wolfgang Denk @ 2006-07-28 21:31 UTC (permalink / raw)
To: Furxhi, Orges; +Cc: linuxppc-embedded
In-Reply-To: <162B449665D6D643AD9E1D50FC6F4B14042F1C97@mdcexc05.na.ops.local>
Dear Orges,
in message <162B449665D6D643AD9E1D50FC6F4B14042F1C97@mdcexc05.na.ops.local> you wrote:
>
> Are you just trying one specific type opf USB device, or does this
> happen with several 5 or more) different devices?
>
> We tried 6 different USB flash drives:
Argh... your message is very difficult to read, as there is no
difference between your text and mine. Please see
http://www.netmeister.org/news/learn2quote.html
Also, please don't send separate mesages to the original poster and
the mailing list; use Cc: instead.
> Are there any flashdrives that are known to always work?
I don't dare to say "always" ;-)
But if you tested so many devices, and none of them is working, then
this is probably an indication of another problem.
Do you have a chance to try a different board? Did you ever
succesfully use *any* USB device on your board? Maybe there is a
hardware problem on your system.
Ummm... stupid question: is the green LED behind the USB connector on
your board on or off?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1
^ permalink raw reply
* RE: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Furxhi, Orges @ 2006-07-28 21:57 UTC (permalink / raw)
To: 'Wolfgang Denk', Furxhi, Orges; +Cc: linuxppc-embedded
Mr, Denk
>But if you tested so many devices, and none of them is working, then
>this is probably an indication of another problem.
It might be, but I can not figure out what it is. I am hoping it is just a
kernel configuration mater.
>Do you have a chance to try a different board? Did you ever
>succesfully use *any* USB device on your board? Maybe there is a
>hardware problem on your system.
I just have one icecube board (Lite5200 Ver 2.0), and I have 4 of our own
custom boards designed after the icecube. Right now I am testing on the
icecube board. I tried our boards but usb as mass storage is not working
there either.
>Ummm... stupid question: is the green LED behind the USB connector on
>your board on or off?
There is one and it was off, I shorted out R164 and the led came on. Our
custom board takes care of this as well
Which defconfig file should I use?
I just tried the icecube_5200_CoralP_defconfig file but now the board is not
booting; it hangs right after this message:
"Uncompressing Kernel Image ... OK"
Thanks,
Orges
PS.
>Argh... your message is very difficult to read, as there is no difference
>between your text and mine.
I assumed that outlook would do it automatically, but apparently it did not,
sorry about that.
>Also, please don't send separate mesages to the original poster and the
>mailing list; use Cc: instead.
I hit "reply" instead of "reply all" by mistake; sorry about that too, I
will not happen again.
^ permalink raw reply
* RE: USB flashdrive on Motorola MPC5200 (IceCube) board, linux ker nel 2.4.25 (DENX drop)
From: Furxhi, Orges @ 2006-07-28 22:07 UTC (permalink / raw)
To: Furxhi, Orges, 'Wolfgang Denk'
Cc: 'linuxppc-embedded@ozlabs.org'
>Which defconfig file should I use?
>I just tried the icecube_5200_CoralP_defconfig file but now the board isnot
>booting; it hangs right after this message:
I figured out my mistake as far as booting the kernel, I did not have the
right bootm argument.
Even with the I figured out my mistake as far as booting the kernel, I did
not have the correct bootargs.
Even with the icecube_5200_CoralP_defconfig +scsi support, and usb
mas-storage enabled, I get the same message when I plug in the usb stick.
usb.c: USB device not accepting new address=2 (error=-110)
Orges
^ permalink raw reply
* Re: Xilinx hard TEMAC
From: David H. Lynch Jr. @ 2006-07-30 1:08 UTC (permalink / raw)
To: Rick Moleres; +Cc: linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C029DC9E5@XCO-EXCHVS1.xlnx.xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]
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@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net 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
[-- Attachment #2: Type: text/html, Size: 5207 bytes --]
^ permalink raw reply
* Re: [RFC] I2C-MPC: Fix up error handling
From: Jean Delvare @ 2006-07-30 11:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sylvain Munaut
In-Reply-To: <20060609095421.7157dc53.khali@linux-fr.org>
Quoting myself:
> Could anyone please comment on this i2c-mpc patch, and give it some
> testing on different systems? I'm fine with the error propagation
> fixes, but less fine with the random resets being added, and rather
> unhappy with the "retry once more just in case" thing, which I think,
> if really needed, should instead be implemented using the standard
> i2c_adapter.retries mechanism.
Can anyone please comment on this patch? Andrew Morton keeps forwarding
it to me, but I don't think I can accept it as is (see my complaints
above.)
> From: Kumar Gala <galak@kernel.crashing.org>
>
> * If we have an Unfinished (MCF) or Arbitration Lost (MAL) error and
> the bus is still busy reset the controller. This prevents the
> controller from getting in a hung state for transactions for other
> devices.
>
> * Fixed up propogating the errors from i2c_wait.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> Cc: Jean Delvare <khali@linux-fr.org>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
> drivers/i2c/busses/i2c-mpc.c | 43 +++++++++++++++++++++++----------
> 1 file changed, 31 insertions(+), 12 deletions(-)
>
> diff -puN drivers/i2c/busses/i2c-mpc.c~i2c-mpc-fix-up-error-handling drivers/i2c/busses/i2c-mpc.c
> --- devel/drivers/i2c/busses/i2c-mpc.c~i2c-mpc-fix-up-error-handling 2006-06-01 20:22:55.000000000 -0700
> +++ devel-akpm/drivers/i2c/busses/i2c-mpc.c 2006-06-01 20:22:55.000000000 -0700
> @@ -115,11 +115,20 @@ static int i2c_wait(struct mpc_i2c *i2c,
>
> if (!(x & CSR_MCF)) {
> pr_debug("I2C: unfinished\n");
> +
> + /* reset the controller if the bus is still busy */
> + if (x & CSR_MBB)
> + writeccr(i2c, 0);
> +
> return -EIO;
> }
>
> if (x & CSR_MAL) {
> pr_debug("I2C: MAL\n");
> +
> + /* reset the controller if the bus is still busy */
> + if (x & CSR_MBB)
> + writeccr(i2c, 0);
> return -EIO;
> }
>
> @@ -160,7 +169,7 @@ static void mpc_i2c_stop(struct mpc_i2c
> static int mpc_write(struct mpc_i2c *i2c, int target,
> const u8 * data, int length, int restart)
> {
> - int i;
> + int i, ret;
> unsigned timeout = i2c->adap.timeout;
> u32 flags = restart ? CCR_RSTA : 0;
>
> @@ -172,15 +181,17 @@ static int mpc_write(struct mpc_i2c *i2c
> /* Write target byte */
> writeb((target << 1), i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + ret = i2c_wait(i2c, timeout, 1);
> + if (ret < 0)
> + return ret;
>
> for (i = 0; i < length; i++) {
> /* Write data byte */
> writeb(data[i], i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + ret = i2c_wait(i2c, timeout, 1);
> + if (ret < 0)
> + return ret;
> }
>
> return 0;
> @@ -190,7 +201,7 @@ static int mpc_read(struct mpc_i2c *i2c,
> u8 * data, int length, int restart)
> {
> unsigned timeout = i2c->adap.timeout;
> - int i;
> + int i, ret;
> u32 flags = restart ? CCR_RSTA : 0;
>
> /* Start with MEN */
> @@ -201,8 +212,9 @@ static int mpc_read(struct mpc_i2c *i2c,
> /* Write target address byte - this time with the read flag set */
> writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
>
> - if (i2c_wait(i2c, timeout, 1) < 0)
> - return -1;
> + ret = i2c_wait(i2c, timeout, 1);
> + if (ret < 0)
> + return ret;
>
> if (length) {
> if (length == 1)
> @@ -214,8 +226,9 @@ static int mpc_read(struct mpc_i2c *i2c,
> }
>
> for (i = 0; i < length; i++) {
> - if (i2c_wait(i2c, timeout, 0) < 0)
> - return -1;
> + ret = i2c_wait(i2c, timeout, 0);
> + if (ret < 0)
> + return ret;
>
> /* Generate txack on next to last byte */
> if (i == length - 2)
> @@ -246,8 +259,13 @@ static int mpc_xfer(struct i2c_adapter *
> return -EINTR;
> }
> if (time_after(jiffies, orig_jiffies + HZ)) {
> - pr_debug("I2C: timeout\n");
> - return -EIO;
> + writeccr(i2c, 0);
> +
> + /* try one more time before we error */
> + if (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
> + pr_debug("I2C: timeout\n");
> + return -EIO;
> + }
> }
> schedule();
> }
> @@ -325,6 +343,7 @@ static int fsl_i2c_probe(struct platform
> goto fail_irq;
> }
>
> + writeccr(i2c, 0);
> mpc_i2c_setclock(i2c);
> platform_set_drvdata(pdev, i2c);
--
Jean Delvare
^ permalink raw reply
* Re: [RFC] I2C-MPC: Fix up error handling
From: Kumar Gala @ 2006-07-30 16:23 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Sylvain Munaut
In-Reply-To: <20060730131440.1d4fcbe6.khali@linux-fr.org>
On Jul 30, 2006, at 6:14 AM, Jean Delvare wrote:
> Quoting myself:
>> Could anyone please comment on this i2c-mpc patch, and give it some
>> testing on different systems? I'm fine with the error propagation
>> fixes, but less fine with the random resets being added, and rather
>> unhappy with the "retry once more just in case" thing, which I think,
>> if really needed, should instead be implemented using the standard
>> i2c_adapter.retries mechanism.
>
> Can anyone please comment on this patch? Andrew Morton keeps
> forwarding
> it to me, but I don't think I can accept it as is (see my complaints
> above.)
If I find some time, let me split out the error propagation so we can
get that fix up stream. The other code was to handle a buggy device
that was connected in one system I was working on.
- kumar
>> From: Kumar Gala <galak@kernel.crashing.org>
>>
>> * If we have an Unfinished (MCF) or Arbitration Lost (MAL) error and
>> the bus is still busy reset the controller. This prevents the
>> controller from getting in a hung state for transactions for other
>> devices.
>>
>> * Fixed up propogating the errors from i2c_wait.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> Cc: Jean Delvare <khali@linux-fr.org>
>> Cc: Greg KH <greg@kroah.com>
>> Signed-off-by: Andrew Morton <akpm@osdl.org>
>> ---
>>
>> drivers/i2c/busses/i2c-mpc.c | 43 ++++++++++++++++++++++
>> +----------
>> 1 file changed, 31 insertions(+), 12 deletions(-)
>>
>> diff -puN drivers/i2c/busses/i2c-mpc.c~i2c-mpc-fix-up-error-
>> handling drivers/i2c/busses/i2c-mpc.c
>> --- devel/drivers/i2c/busses/i2c-mpc.c~i2c-mpc-fix-up-error-
>> handling 2006-06-01 20:22:55.000000000 -0700
>> +++ devel-akpm/drivers/i2c/busses/i2c-mpc.c 2006-06-01
>> 20:22:55.000000000 -0700
>> @@ -115,11 +115,20 @@ static int i2c_wait(struct mpc_i2c *i2c,
>>
>> if (!(x & CSR_MCF)) {
>> pr_debug("I2C: unfinished\n");
>> +
>> + /* reset the controller if the bus is still busy */
>> + if (x & CSR_MBB)
>> + writeccr(i2c, 0);
>> +
>> return -EIO;
>> }
>>
>> if (x & CSR_MAL) {
>> pr_debug("I2C: MAL\n");
>> +
>> + /* reset the controller if the bus is still busy */
>> + if (x & CSR_MBB)
>> + writeccr(i2c, 0);
>> return -EIO;
>> }
>>
>> @@ -160,7 +169,7 @@ static void mpc_i2c_stop(struct mpc_i2c
>> static int mpc_write(struct mpc_i2c *i2c, int target,
>> const u8 * data, int length, int restart)
>> {
>> - int i;
>> + int i, ret;
>> unsigned timeout = i2c->adap.timeout;
>> u32 flags = restart ? CCR_RSTA : 0;
>>
>> @@ -172,15 +181,17 @@ static int mpc_write(struct mpc_i2c *i2c
>> /* Write target byte */
>> writeb((target << 1), i2c->base + MPC_I2C_DR);
>>
>> - if (i2c_wait(i2c, timeout, 1) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 1);
>> + if (ret < 0)
>> + return ret;
>>
>> for (i = 0; i < length; i++) {
>> /* Write data byte */
>> writeb(data[i], i2c->base + MPC_I2C_DR);
>>
>> - if (i2c_wait(i2c, timeout, 1) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 1);
>> + if (ret < 0)
>> + return ret;
>> }
>>
>> return 0;
>> @@ -190,7 +201,7 @@ static int mpc_read(struct mpc_i2c *i2c,
>> u8 * data, int length, int restart)
>> {
>> unsigned timeout = i2c->adap.timeout;
>> - int i;
>> + int i, ret;
>> u32 flags = restart ? CCR_RSTA : 0;
>>
>> /* Start with MEN */
>> @@ -201,8 +212,9 @@ static int mpc_read(struct mpc_i2c *i2c,
>> /* Write target address byte - this time with the read flag set */
>> writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
>>
>> - if (i2c_wait(i2c, timeout, 1) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 1);
>> + if (ret < 0)
>> + return ret;
>>
>> if (length) {
>> if (length == 1)
>> @@ -214,8 +226,9 @@ static int mpc_read(struct mpc_i2c *i2c,
>> }
>>
>> for (i = 0; i < length; i++) {
>> - if (i2c_wait(i2c, timeout, 0) < 0)
>> - return -1;
>> + ret = i2c_wait(i2c, timeout, 0);
>> + if (ret < 0)
>> + return ret;
>>
>> /* Generate txack on next to last byte */
>> if (i == length - 2)
>> @@ -246,8 +259,13 @@ static int mpc_xfer(struct i2c_adapter *
>> return -EINTR;
>> }
>> if (time_after(jiffies, orig_jiffies + HZ)) {
>> - pr_debug("I2C: timeout\n");
>> - return -EIO;
>> + writeccr(i2c, 0);
>> +
>> + /* try one more time before we error */
>> + if (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
>> + pr_debug("I2C: timeout\n");
>> + return -EIO;
>> + }
>> }
>> schedule();
>> }
>> @@ -325,6 +343,7 @@ static int fsl_i2c_probe(struct platform
>> goto fail_irq;
>> }
>>
>> + writeccr(i2c, 0);
>> mpc_i2c_setclock(i2c);
>> platform_set_drvdata(pdev, i2c);
>
> --
> Jean Delvare
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox