* 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 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: 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: [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: [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: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: 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: 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
* 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
* 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
* 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
* 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
* 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: 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: 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
* 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
* 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
* 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
* 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:System Ace Driver Hangs.
From: Raja Chidambaram @ 2006-07-28 11:03 UTC (permalink / raw)
To: ammubhai, eemingliu, linuxppc-embedded
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: Booting Linux Kernel without bootloader
From: David H. Lynch Jr. @ 2006-07-28 8:03 UTC (permalink / raw)
To: Clint Thomas, linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952915DF66@bluefin.Soneticom.local>
[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]
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.
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
[-- Attachment #2: Type: text/html, Size: 3667 bytes --]
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Benjamin Herrenschmidt @ 2006-07-28 4:56 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154024154.29826.229.camel@goblue>
On Thu, 2006-07-27 at 13:15 -0500, Jake Moilanen wrote:
> Here is a rebased RTAS MSI which uses the IRQ layer rewrite. Please try
> getting it into 2.6.18.
>
> I mistakenly forgot to export the MSI symbols. So modules weren't too
> happy...
>
> 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.
Ben.
^ permalink raw reply
* [PATCH] Enable PURR sysfs entry correctly
From: Michael Neuling @ 2006-07-28 3:58 UTC (permalink / raw)
To: paulus, linuxppc-dev
We have CPU_FTR_PURR now, so let's use it.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/sysfs.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/sysfs.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/sysfs.c
@@ -231,7 +231,7 @@ static void register_cpu_online(unsigned
if (cur_cpu_spec->num_pmcs >= 8)
sysdev_create_file(s, &attr_pmc8);
- if (cpu_has_feature(CPU_FTR_SMT))
+ if (cpu_has_feature(CPU_FTR_PURR))
sysdev_create_file(s, &attr_purr);
}
@@ -273,7 +273,7 @@ static void unregister_cpu_online(unsign
if (cur_cpu_spec->num_pmcs >= 8)
sysdev_remove_file(s, &attr_pmc8);
- if (cpu_has_feature(CPU_FTR_SMT))
+ if (cpu_has_feature(CPU_FTR_PURR))
sysdev_remove_file(s, &attr_purr);
}
#endif /* CONFIG_HOTPLUG_CPU */
^ permalink raw reply
* [PATCH] Add rtas_set_indicator_fast() for RTAS call without extended delay
From: Haren Myneni @ 2006-07-27 21:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: External List, Nathan Lynch, Milton Miller
In-Reply-To: <20060726220441.GZ19076@localdomain>
[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]
Nathan Lynch wrote:
>Looks fine to me from a quick look, but we need to use
>rtas_set_indicator_fast in xics_setup_cpu as well (I think I neglected
>to mention I saw the warning in the cpu up path, sorry).
>
>
>
Posting the modified patch based on Nathan's comment - using
rtas_set_indicator_fast() in xics_setup_cpu(). If Ok, please send it to
upstream.
Thanks
Haren
Noticing the following might_sleep warning (dump_stack()) during kdump
testing when CONFIG_DEBUG_SPINLOCK_SLEEP is enabled. All secondary CPUs
will be calling rtas_set_indicator with interrupts disabled to remove
them from global interrupt queue.
BUG: sleeping function called from invalid context at
arch/powerpc/kernel/rtas.c:463
in_atomic():1, irqs_disabled():1
Call Trace:
[C00000000FFFB970] [C000000000010234] .show_stack+0x68/0x1b0 (unreliable)
[C00000000FFFBA10] [C000000000059354] .__might_sleep+0xd8/0xf4
[C00000000FFFBA90] [C00000000001D1BC] .rtas_busy_delay+0x20/0x5c
[C00000000FFFBB20] [C00000000001D8A8] .rtas_set_indicator+0x6c/0xcc
[C00000000FFFBBC0] [C000000000048BF4] .xics_teardown_cpu+0x118/0x134
[C00000000FFFBC40] [C00000000004539C]
.pseries_kexec_cpu_down_xics+0x74/0x8c
[C00000000FFFBCC0] [C00000000002DF08] .crash_ipi_callback+0x15c/0x188
[C00000000FFFBD50] [C0000000000296EC] .smp_message_recv+0x84/0xdc
[C00000000FFFBDC0] [C000000000048E08] .xics_ipi_dispatch+0xf0/0x130
[C00000000FFFBE50] [C00000000009EF10] .handle_IRQ_event+0x7c/0xf8
[C00000000FFFBF00] [C0000000000A0A14] .handle_percpu_irq+0x90/0x10c
[C00000000FFFBF90] [C00000000002659C] .call_handle_irq+0x1c/0x2c
[C00000000058B9C0] [C00000000000CA10] .do_IRQ+0xf4/0x1a4
[C00000000058BA50] [C0000000000044EC] hardware_interrupt_entry+0xc/0x10
--- Exception: 501 at .plpar_hcall_norets+0x14/0x1c
LR = .pseries_dedicated_idle_sleep+0x190/0x1d4
[C00000000058BD40] [C00000000058BDE0] 0xc00000000058bde0 (unreliable)
[C00000000058BDF0] [C00000000001270C] .cpu_idle+0x10c/0x1e0
[C00000000058BE70] [C000000000009274] .rest_init+0x44/0x5c
To fix this issue, rtas_set_indicator_fast() is added so that will not
wait for RTAS 'busy' delay and this new function is used for kdump (in
xics_teardown_cpu()) and for CPU hotplug ( xics_migrate_irqs_away() and
xics_setup_cpu()).
Signed-off-by: Haren Myneni <haren@us.ibm.com>
[-- Attachment #2: ppc64-add-rtas-set-indicator-fast.patch --]
[-- Type: text/x-patch, Size: 2754 bytes --]
diff -Naurp 2618-rc2.orig/arch/powerpc/kernel/rtas.c 2618-rc2/arch/powerpc/kernel/rtas.c
--- 2618-rc2.orig/arch/powerpc/kernel/rtas.c 2006-07-25 19:34:11.000000000 -0700
+++ 2618-rc2/arch/powerpc/kernel/rtas.c 2006-07-25 19:33:16.000000000 -0700
@@ -569,6 +569,27 @@ int rtas_set_indicator(int indicator, in
}
EXPORT_SYMBOL(rtas_set_indicator);
+/*
+ * Ignoring RTAS extended delay
+ */
+int rtas_set_indicator_fast(int indicator, int index, int new_value)
+{
+ int rc;
+ int token = rtas_token("set-indicator");
+
+ if (token == RTAS_UNKNOWN_SERVICE)
+ return -ENOENT;
+
+ rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
+
+ WARN_ON(rc == -2 || (rc >= 9900 && rc <= 9905));
+
+ if (rc < 0)
+ return rtas_error_rc(rc);
+
+ return rc;
+}
+
void rtas_restart(char *cmd)
{
if (rtas_flash_term_hook)
diff -Naurp 2618-rc2.orig/arch/powerpc/platforms/pseries/xics.c 2618-rc2/arch/powerpc/platforms/pseries/xics.c
--- 2618-rc2.orig/arch/powerpc/platforms/pseries/xics.c 2006-07-25 19:34:41.000000000 -0700
+++ 2618-rc2/arch/powerpc/platforms/pseries/xics.c 2006-07-26 16:30:16.000000000 -0700
@@ -467,7 +467,7 @@ void xics_setup_cpu(void)
*
* XXX: undo of teardown on kexec needs this too, as may hotplug
*/
- rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
+ rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
(1UL << interrupt_server_size) - 1 - default_distrib_server, 1);
}
@@ -796,7 +796,7 @@ void xics_teardown_cpu(int secondary)
* so leave the master cpu in the group.
*/
if (secondary)
- rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
+ rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
(1UL << interrupt_server_size) - 1 -
default_distrib_server, 0);
}
@@ -813,7 +813,7 @@ void xics_migrate_irqs_away(void)
xics_set_cpu_priority(cpu, 0);
/* remove ourselves from the global interrupt queue */
- status = rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
+ status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
(1UL << interrupt_server_size) - 1 - default_distrib_server, 0);
WARN_ON(status < 0);
diff -Naurp 2618-rc2.orig/include/asm-powerpc/rtas.h 2618-rc2/include/asm-powerpc/rtas.h
--- 2618-rc2.orig/include/asm-powerpc/rtas.h 2006-07-25 19:34:27.000000000 -0700
+++ 2618-rc2/include/asm-powerpc/rtas.h 2006-07-25 19:33:57.000000000 -0700
@@ -170,6 +170,7 @@ extern int rtas_get_sensor(int sensor, i
extern int rtas_get_power_level(int powerdomain, int *level);
extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
extern int rtas_set_indicator(int indicator, int index, int new_value);
+extern int rtas_set_indicator_fast(int indicator, int index, int new_value);
extern void rtas_progress(char *s, unsigned short hex);
extern void rtas_initialize(void);
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Segher Boessenkool @ 2006-07-27 20:35 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154028871.29826.261.camel@goblue>
>> These two lines don't need the msi.o and msi-altix.o AFAICS.
>
> Yup, you are right...updated patch included below.
Looks fine now, thanks.
>>> +msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
>>
>> I think this file should live in arch/powerpc, and so should this
>> Makefile fragment.
>
> I'm following the current MSI methodologies where arch specific MSI
> code
> lives in drivers/pci. This is just like msi-altix.c.
True, but our core support lives in arch/. The same is true for PHB
code etc.; if Altix messed this up, that doesn't mean we need to :-)
>> Other than that, can we please have the part that doesn't build the
>> "generic" MSI stuff included ASAP?
This would naturally fall out as a separate patch then, as well.
>>> Index: 2.6-msi/drivers/pci/msi-rtas.c
>>
>> Maybe msi-papr.c is a better name btw? Not that I care :-)
>
> IMHO I don't like PAPR names because they like changing them on a
> whim.
> RTAS is a bit more persistent.
Maybe msi-pseries then? Oh wait, they changed that name too ;-)
> I don't really care...If anyone feels real strongly about it, I'll
> change it.
If you move this code to arch/powerpc/platforms/pseries/, you could
just call it "msi.c". I don't like the msi-rtas name -- but, I don't
feel that strongly about it, just a suggestion.
Segher
^ 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