* Re: [PATCH] ppc: remove unused amiga_request_irq and mach_request_irq
From: Fernando Luis Vázquez Cao @ 2007-08-23 5:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <18124.1417.743332.974941@cargo.ozlabs.ibm.com>
On Wed, 2007-08-22 at 19:44 +1000, Paul Mackerras wrote:
> Fernando Luis Vázquez Cao writes:
>
> > amiga_request_irq and mach_request_irq are never used, so delete them.
>
> OK, but is there a particular reason you want to do this?
Hi Paul,
Thank you for your reply.
I am currently auditing all the interrupt handlers and related code
(request_irq(), free_irq(), and others of that ilk) and, in the process,
I found some dead code. Getting rid of this cruft would just make my
life easier.
The final goal of this audit is to determine whether the Linux interrupt
handlers are kdump-ready. With the advent of kdump it is now possible
that device drivers have to handle pending interrupts generated in the
context of a previous kernel. Any pending interrupts will come in as
soon as the IRQ is allocated, but, unfortunately, not all the device
drivers handle this situation properly.
Besides, I am also trying to determine if applying this patch:
http://lkml.org/lkml/2007/7/19/687
is a sane thing to do.
> The whole of arch/ppc is going away eventually, so I don't think we
> need to remove it piece by piece.
As Linas mentioned in his reply, cleaning things up first will probably
make things easier for you too.
Please consider merging the four patches I sent to the PPC mailing list.
Fernando
^ permalink raw reply
* Re: [PATCH] ppc: remove unused amiga_request_irq and mach_request_irq
From: Fernando Luis Vázquez Cao @ 2007-08-23 5:29 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20070822182859.GX4261@austin.ibm.com>
On Wed, 2007-08-22 at 13:28 -0500, Linas Vepstas wrote:
> On Wed, Aug 22, 2007 at 07:44:41PM +1000, Paul Mackerras wrote:
> > Fernando Luis Vázquez Cao writes:
> >
> > > amiga_request_irq and mach_request_irq are never used, so delete them.
> >
> > OK, but is there a particular reason you want to do this?
> >
> > The whole of arch/ppc is going away eventually, so I don't think we
> > need to remove it piece by piece.
>
> Its often easier to port/move stuff if you clean it up first.
Agreed. It would make things easier for me too.
Fernando
^ permalink raw reply
* Re: bogus vscsi dt node on iseries
From: Olaf Hering @ 2007-08-23 5:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070823133621.830245c4.sfr@canb.auug.org.au>
On Thu, Aug 23, Stephen Rothwell wrote:
> On Wed, 22 Aug 2007 19:51:21 +0200 Olaf Hering <olaf@aepfle.de> wrote:
> >
> >
> > Does anyone know why dt_vdevices() creates a vscsi node on legacy iseries?
> > I'm sure only viodasd and viocd is required as blockdevice type.
>
> Because the IBM vscsi client (in theory) works on legacy iSeries.
I'm asking because there are many unneeded nodes.
Have you tried to create only the nodes for disks/cds that are really
present and modify viodasd to use only device-tree data?
^ permalink raw reply
* Re: Need the bdi cfg file for taihu PPCEP405 Eval board
From: Stefan Roese @ 2007-08-23 5:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF4E3437FA.70738D18-ON8525733F.00715D10-8525733F.007168AC@rflelect.com>
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
On Wednesday 22 August 2007, ravi.rao@rflelect.com wrote:
> Can one of you please email me the bdi config file for Taihu Eval
> board. I need to attach bdi200 and do some debugging on that..
I don't have a config file for the Taihu, but I attached one for a board
that's quite similar to the AMCC Taihu. Needs some small changes perhaps.
Just give it a try.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
[-- Attachment #2: zeus.cfg --]
[-- Type: text/plain, Size: 3186 bytes --]
;bdiGDB configuration file for Zeus for U-Boot
; --------------------------------------------
;
[INIT]
; init core register
WSPR 954 0x00000000 ;DCWR: Disable data cache write-thru
WSPR 1018 0x00000000 ;DCCR: Disable data cache
WSPR 1019 0x00000000 ;ICCR: Disable instruction cache
WSPR 982 0xFFF80000 ;EVPR: Exception Vector Table @0x00000000
;
WDCR 0x0F9 0x00000010 ; enable WR# (PCI_INT/WR# multiplexing)
; Setup PLL
; CPU=133MHz
; PLB=133MHz
; OPB=66MHz
; EBC=33MHz
WDCR 0x0F0 0x00001203
WDCR 0x0F4 0x8042223E
; Setup Peripheral Bus
; CS0 (default mode)
WDCR 18 0x00000010 ;Select PB0AP
WDCR 19 0x05815600 ;PB0AP: NOR Flash/SRAM
WDCR 18 0x00000000 ;Select PB0CR
WDCR 19 0xff09a000 ;PB0CR: BAS=0xFF0,BS=4MB,BU=R/W,BW=16bit
; Setup SDRAM Controller
WDCR 16 0x00000080 ;Select SDTR1
WDCR 17 0x01074015 ;SDTR1: SDRAM Timing Register
WDCR 16 0x00000040 ;Select MB0CF
WDCR 17 0x00084001 ;MB0CF: 16MB @ 0x00000000
WDCR 16 0x00000030 ;Select RTR
WDCR 17 0x07f00000 ;RTR: Refresh Timing Register
WDCR 16 0x00000020 ;Select MCOPT1
WDCR 17 0x80800000 ;MCOPT1: Enable SDRAM Controller
; Setup MMU info - these lines must be uncommented to debug Linux kernel
;WM32 0x000000f4 0x00000000 ;invalidate kernel page table base
;WM32 0x000000f8 0x00000000 ;invalidate process page table base
;WM32 0x000000f0 0xc00000f4 ;invalidate page table base
; Setup OCM
WDCR 0x01A 0xEC000000
WDCR 0x01B 0xC0000000
[TARGET]
JTAGCLOCK 0 ;use 16 MHz JTAG clock
CPUTYPE 405 ;the used target CPU type
BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT)
WAKEUP 1000 ;wakeup time after reset
BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware breakpoint
STEPMODE HWBP ;JTAG or HWBP, HWPB uses one or two hardware breakpoints
;VECTOR CATCH ;catch unhandled exceptions
;MMU XLAT 0xC0000000 ;enable virtual address mode
;PTBASE 0x000000f0 ;address where kernel/user stores pointer to page table
;SIO 7 9600 ;TCP port for serial IO
;REGLIST SPR ;select register to transfer to GDB
REGLIST ALL ;select register to transfer to GDB
;SCANPRED 2 2 ;JTAG devices connected before PPC400
;SCANSUCC 3 3 ;JTAG devices connected after PPC400
[HOST]
IP 10.0.0.152
FORMAT BIN
FILE /tftpboot/zeus/u-boot.bin
LOAD MANUAL ;load code MANUAL or AUTO after reset
DEBUGPORT 2001
PROMPT zeus>
[FLASH]
WORKSPACE 0x100000 ;workspace in on-chip SRAM for fast programming algorithm
CHIPTYPE MIRRORX16 ;Flash type
CHIPSIZE 0x1000000 ;16MB The size of one flash chip in bytes
BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32)
FILE /tftpboot/zeus/u-boot.bin
FORMAT BIN 0xFFFC0000
; Erase just the last seven blocks for U-Boot
ERASE 0xFFFC0000
ERASE 0xFFFE0000
[REGS]
IDCR1 0x010 0x011 ;MEMCFGADR and MEMCFGDATA
IDCR2 0x012 0x013 ;EBCCFGADR and EBCCFGDATA
;IDCR3 0x014 0x015 ;KIAR and KIDR
FILE /tftpboot/BDI2000/reg405ep.def
^ permalink raw reply
* STK5200 pci_enable_device problem
From: Mustafa Cayır @ 2007-08-23 5:42 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am working on TQ STK52000 development board with TQM5200-AB cpu =
module. I am trying to use PCI bus and Local Plus Bus together. SM501, =
video chip is located on local plus bus and PLX9030 based pci device is =
on pci bus.
My pci driver is able to scan pci bus and find succesfully the pci =
device. After this point, pci_enable_device function returns following =
error:
PCI: Device 00:18.0 not available because of resource collisions
Any help is appreciated.
^ permalink raw reply
* Re: bogus vscsi dt node on iseries
From: Stephen Rothwell @ 2007-08-23 5:59 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20070823054239.GA24251@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
On Thu, 23 Aug 2007 07:42:39 +0200 Olaf Hering <olaf@aepfle.de> wrote:
>
> On Thu, Aug 23, Stephen Rothwell wrote:
>
> > On Wed, 22 Aug 2007 19:51:21 +0200 Olaf Hering <olaf@aepfle.de> wrote:
> > >
> > >
> > > Does anyone know why dt_vdevices() creates a vscsi node on legacy iseries?
> > > I'm sure only viodasd and viocd is required as blockdevice type.
> >
> > Because the IBM vscsi client (in theory) works on legacy iSeries.
>
> I'm asking because there are many unneeded nodes.
> Have you tried to create only the nodes for disks/cds that are really
> present and modify viodasd to use only device-tree data?
I'll have a look, but that would require interacting with the hypervisor
very early in the boot sequence ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Section mismatch warning
From: sivaji @ 2007-08-23 6:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <C5046FD2-6781-4E6E-847B-1BDB24E5D81F@kernel.crashing.org>
Hi,
I applied the patch(13066). After that i got following error.
arch/powerpc/kernel/vmlinux.lds:59: parse error
I added the following lines in the vmlinux.lds file
ALIGN_FUNCTION();
*(.text.head)
Then i removed the ALIGN_FUNCTION() in the vmlinux.lds file. The parse error
was overcome. I don't know after removing the ALIGN_FUNCTION why the error
was overcome.
>
> Hi,
> When compiling the 2.6.23-rc3 kernel, i got following warning
> messages.
>
> WARNING: vmlinux.o(.text+0x18): Section mismatch: reference to
> .init.text:early_init (between '__start' and '__after_mmu_off')
> WARNING: vmlinux.o(.text+0x3834): Section mismatch: reference to
> .init.text:machine_init (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x383c): Section mismatch: reference to
> .init.text:MMU_init (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x3866): Section mismatch: reference to
> .init.text:start_kernel (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x386a): Section mismatch: reference to
> .init.text:start_kernel (between 'start_here' and 'set_context')
>
> Processor : 8641D
> Give some idea how to overcome this warning.
There is a patch posted on the list for this. I doubt will fix these
for 2.6.23 as they are just warnings.
http://patchwork.ozlabs.org/linuxppc/patch?id=13066
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
View this message in context: http://www.nabble.com/Section-mismatch-warning-tf4315101.html#a12288012
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Size swapper_pg_dir correctly
From: Stephen Rothwell @ 2007-08-23 6:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev, paulus
In-Reply-To: <DDBA4998-5BCC-413A-9759-3815693A68E6@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
On Wed, 22 Aug 2007 22:26:35 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> > +#ifdef CONFIG_PPC64
> > + DEFINE(PGD_TABLE_SIZE, PGD_TABLE_SIZE);
> > +#endif
>
> Why limit this to ppc64? The cleanup should be reasonable for all ppc.
Because PGD_TABLE_SIZE only exists for ppc64 :-) for ppc32 the
swapper_pg_dir will always be 1 page, right?
So we could have
#define PGD_TABLE_SIZE PAGE_SIZE
for 32 bit and then go around and change the swapper_pg_dir's, but that
would be a separate patch.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: David H. Lynch Jr. @ 2007-08-23 6:43 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20070818205752.049d2bc6@vader.jdub.homelinux.org>
Josh Boyer wrote:
>> arch/boot/simple/embed_config.c jusst seems to be a random collection
>> of board specific code anyway.
>> A giant case statement implimented with #ifdef's. It is just
>> screaming to be done some better way.
>>
>> You mean like a device tree? ;)
>>
>> josh
>>
Maybe, I am waiting to see somebody move something to device tree so
that I can get a better grasp of what it is and how it works.
From what little I know I think it is going to be very significant for
my BSP - we are trying to use a single binary for alot of different
boards, or the same board with different firmware. From what I am
gathering I can have the loader pass a device tree to the kernel
and the device tree will basically describe the hardware to the kernel.
Only at the moment I don't have the time to learn enough to attempt to
lead the charge moving xilinx stuff to powerpc.
Is there a way to do this in small peices ?
It would be nice to end some of the debate on how to setup ppc/4xx for
multiple xilinx targets and just get it over with and move to powerpc
device tree, ...
But I can't beat others up for what I can't find time for myself.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 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
^ permalink raw reply
* Re: wmb vs mmiowb
From: Benjamin Herrenschmidt @ 2007-08-23 7:25 UTC (permalink / raw)
To: Nick Piggin; +Cc: Linus Torvalds, linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <20070822045714.GD26374@wotan.suse.de>
On Wed, 2007-08-22 at 06:57 +0200, Nick Piggin wrote:
> It doesn't seem like this primary function of mmiowb has anything to do
> with a write barrier that we are used to (it may have a seconary semantic
> of a wmb as well, but let's ignore that for now). A write barrier will
> never provide you with those semantics (writes from 2 CPUs seen in the
> same order by a 3rd party). If anything, I think it is closer to being
> a read barrier issued on behalf of the target device. But even that I
> think is not much better, because the target is not participating in the
> synchronisation that the CPUs are, so the "read barrier request" could
> still arrive at the device out of order WRT the other CPU's writes.
>
> It really seems like it is some completely different concept from a
> barrier. And it shows, on the platform where it really matters (sn2), where
> the thing actually spins.
The way mmiowb was actually defined to me by the ia64 folks who came up
with it is essentially to order an MMIO write with a spin_unlock.
Ben.
^ permalink raw reply
* Re: wmb vs mmiowb
From: Benjamin Herrenschmidt @ 2007-08-23 7:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nick Piggin, linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <alpine.LFD.0.999.0708221049560.30176@woody.linux-foundation.org>
> Of course, the normal memory barrier would usually be a "spin_unlock()" or
> something like that, not a "wmb()". In fact, I don't think the powerpc
> implementation (as an example of this) will actually synchronize with
> anything *but* a spin_unlock().
We are even more sneaky in the sense that we set a per-cpu flag on any
MMIO write and do the sync automatically in spin_unlock() :-)
Ben.
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: Benjamin Herrenschmidt @ 2007-08-23 7:30 UTC (permalink / raw)
To: David Gibson; +Cc: netdev, Jeff Garzik, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070823035601.GL7042@localhost.localdomain>
On Thu, 2007-08-23 at 13:56 +1000, David Gibson wrote:
>
>
> Jeff, I've discussed this with BenH, and although there are some
> problems with the driver still, we think it's good enough to merge in
> 2.6.24, the warts can be fixed up later. Please apply...
Or to be more precise:
This driver will work well for 4xx platforms and will allow us to move a
big step toward getting rid of arch/ppc. The issues with DMA mapping
really only concern the case where this is used within the cell "Axon"
southbridge, which doesn't happen on any released product at this stage.
Ben.
^ permalink raw reply
* Re: Driver for device behind a PCI-VME bridge
From: Konstantin Boyanov @ 2007-08-23 7:47 UTC (permalink / raw)
To: Johan Borkhuis; +Cc: linuxppc-embedded
In-Reply-To: <46CAE973.6040306@dutchspace.nl>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Hi again,
First of all thanks for reply.
> I attached a diff to the 3.7 version of the Motorola patch. I hope this
> will help you. This is not the Xenomai version, but the standard version
> with VME interrupts per level. The mechanism for Xenomai is identical,
> but I don't know yet about the legal status of this. The attached patch
> has also been provided to Motorola.
I've got the 3.5 version of the driver, and tried to find newer one. Where
do you get this new releases and patches?
Nevertheless thanks for the patch.
I also had some ssh problems, but AFAICR I had to enable UNIX98PTYS and
> BSDPTYS, and create the entries in /dev/ for the BSD ptys (/dev/ttypXX
> and /dev/ptyXX).
I also had these two options enabled, but still the kernel hangs at boot
time just after trying to initialize SCSI devices... Without Xenomai this
problem doesn't occur. I'm wondering what is that makes Xenomai mess up
things so badly?
Best regards,
Konstantin Boyanov
[-- Attachment #2: Type: text/html, Size: 1412 bytes --]
^ permalink raw reply
* Re: Driver for device behind a PCI-VME bridge
From: Johan Borkhuis @ 2007-08-23 8:24 UTC (permalink / raw)
To: Konstantin Boyanov; +Cc: linuxppc-embedded
In-Reply-To: <929bf310708230047n70bfe883gb963eba6e254b479@mail.gmail.com>
Konstantin Boyanov wrote:
> Hi again,
>
> First of all thanks for reply.
>
>
> I attached a diff to the 3.7 version of the Motorola patch. I hope
> this
> will help you. This is not the Xenomai version, but the standard
> version
> with VME interrupts per level. The mechanism for Xenomai is identical,
> but I don't know yet about the legal status of this. The attached
> patch
> has also been provided to Motorola.
>
>
> I've got the 3.5 version of the driver, and tried to find newer one.
> Where do you get this new releases and patches?
> Nevertheless thanks for the patch.
We got this patch directly from Motorola. Officially Motorola does not
support Linux, but you can ask Ajit Prem (Ajit.Prem@motorola.com) for
the latest version of the patch. As far as I know there is a patch
availeble for 2.6.14 and 2.6.20, but as you have a patch for 2.6.15
already it should not be to difficult to move the 2.6.14 patch to 2.6.15.
>
> I also had some ssh problems, but AFAICR I had to enable
> UNIX98PTYS and
> BSDPTYS, and create the entries in /dev/ for the BSD ptys
> (/dev/ttypXX
> and /dev/ptyXX).
>
>
> I also had these two options enabled, but still the kernel hangs at
> boot time just after trying to initialize SCSI devices... Without
> Xenomai this problem doesn't occur. I'm wondering what is that makes
> Xenomai mess up things so badly?
I did not try SCSI on my system I just disabled all devices that I don't
need, including SCSI. You could try disabling these devices for the
moment (or build them as modules and load these later by hand) and see
if that works, or that there are other problems.
If the problem is still there, you could try the Xenomai mailing list
(see www.xenomai.org).
Kind regards,
Johan Borkhuis
--
Johan Borkhuis Dutch Space BV
email: j.borkhuis@dutchspace.nl Newtonweg 1
phone: 071-5245788 Leiden
fax: 071-5245499 The Netherlands
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Oliver Rutsch @ 2007-08-23 7:24 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <7B9A8FF57DBB524190E98CABF6E56F078FAE4E@itri.bte.mam.gov.tr>
Hi Mustafa,
> Hi all,
>
[...]
>
> My pci driver is able to scan pci bus and find succesfully the pci
> device. After this point, pci_enable_device function returns
> following error:
>
> PCI: Device 00:18.0 not available because of resource collisions
>
Which ELDK and kernel do you use? I had the same problem on this board
with a PLX9054 based PCI card on a 2.4.25 kernel. I switched to the 2.6
kernel and the 4.1 ELDK and the card was scanned correctly.
But keep in mind that the linux PLX drivers do not work out of the box
with a big endian platform like the MPC5200. Although there is a
BIG_ENDIAN flag in the makefiles there are still some places left in the
driver code which have to be patched (the parts with int64 adresses).
It's not so easy to compile the PLX drivers on the 4.1 ELDK because of
missing headers in the ppc architecture. I managed to build the drivers
for the 2.6.19 kernel and I was able to work with the card except the
DMA routines (still working on this issue).
Hope this helps. Bye,
--
Dipl. Ing. Oliver Rutsch
^ permalink raw reply
* Re: 2.6.23-rc3 is not booting
From: sivaji @ 2007-08-23 9:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <BEAC6061-FBAC-45EE-9D2A-C0904DDFECAD@kernel.crashing.org>
Hi,
I am using 8641D processor and the silicon revision is 2.0.
Part : MPC8641D
Revision: 2.0
e600 Core Revision: 2.2
DeviceMarking: B
Processor Version Register Value: 0x8004_0202
System Version Register Value: 0x8090_0120
by
Sivaji
>
> Hai,
> I am using the kernel 2.6.23-rc3. i am trying to boot this
> kernel
> to my 8641D board. It was not booting.
> I go the following message
>
> Bytes transferred = 1505 (5e1 hex)
> ## Booting image at 00200000 ...
> Image Name: Linux-2.6.23-rc3
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1801717 Bytes = 1.7 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using flat device tree at 0x800000
>
> Whether the problem belongs to device tree? I am using the
> mpc8641_hpcn.dts
> file
>
> Pls Advice me.
What rev board/silicon do you have? I'd suggest building the kernel
w/o PCI support and see what happens. Make sure you've got the
latest dts from the kernel tree.
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
View this message in context: http://www.nabble.com/2.6.23-rc3-is-not-booting-tf4309661.html#a12290295
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Geert Uytterhoeven @ 2007-08-23 9:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, David Gibson
In-Reply-To: <F19C9986-9E53-47F3-835D-C93DA9C3ADED@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2269 bytes --]
On Wed, 22 Aug 2007, Kumar Gala wrote:
> On Aug 22, 2007, at 10:33 PM, David Gibson wrote:
> > On Wed, Aug 22, 2007 at 10:33:55PM -0500, Kumar Gala wrote:
> >> On Aug 22, 2007, at 10:19 AM, Kumar Gala wrote:
> >>> I was wondering if I could get your help with looking at the
> >>> following lists and determining if we have an issue or not related
> >>> the following files:
> >>>
> >>> Getting some classification on these would be good. Possibly
> >>> classifications, doesn't build in ARCH=powerpc, remove include, real
> >>> issue, etc.
> >>>
> >> My analysis of <asm/bootinfo.h> usage:
> >>
> >> ./drivers/macintosh/adb-iop.c:#include <asm/bootinfo.h> remove
> >> ./drivers/char/vme_scc.c:#include <asm/bootinfo.h> 68k only
> >> ./drivers/char/serial167.c:#include <asm/bootinfo.h> 68k only
> >> ./drivers/serial/dz.c:#include <asm/bootinfo.h> decstation
> >> ./drivers/mtd/devices/ms02-nv.c:#include <asm/bootinfo.h> decstation
> >> ./drivers/net/macsonic.c:#include <asm/bootinfo.h> 68k
> >> ./drivers/net/jazzsonic.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/pmag-aa-fb.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/maxinefb.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/logo/logo.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/macfb.c:#include <asm/bootinfo.h> 68k
> >> ./drivers/video/valkyriefb.c:#include <asm/bootinfo.h> 68k
> >
> > Uh.. I'm pretty sure valkyriefb.c is for (old) PowerMacs, not 68k.
>
> It appears to be both. If you look at the include its protected by a
> #ifdef CONFIG_MAC which we is only defined on m68k.
Indeed, drivers/video/Kconfig says it depends on MAC || (PPC_PMAC && PPC32)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: signals handling in the kernel
From: Mirek23 @ 2007-08-23 10:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46C9C70D.9080903@ovro.caltech.edu>
Hi David,
Thank you for your hints. I was not aware about race conditions in
signal handling routines. So far I did not noticed any anomalies when
running my server since I use only one interrupt which refers to only one
signal.
I would be interested however in the solution you have suggested with:
SIGIO and fasync()
Would you be so kind to provide me with some example code.
Best Regards
Mirek
David Hawkins-3 wrote:
>
> Hi Mirek,
>
>> In my case I found somehow more convenient to deal with
>> signals.
>
> Ok.
>
>> The server program which I use was originally written
>> for VxWorks. In VxWorks there was no separation betwenn
>> the user and kernel space. When the interrupt occured
>> in VxWorks the interrupt service routine was called.
>> The interrupt service routine was implemented in the server.
>>
>> I found it somehow easier to use signals to trigger signal handler
>> (previously in VxWorks interrupt service routine) than changing the
>> structure of the server to deal with select().
>
> I guess it depends on what you consider 'easier'.
> Signals have potential race conditions, and so using
> select() is safer. I find it 'easier' to have less
> problems, so would spend the time to make the server
> use select().
>
> But, you are free to ignore this advice. :)
>
>> I hope however that there is no fundamental problem with
>> sending signals from kernel (interrupt service routine)
>> to the user space.
>
> There are potential race conditions. I'm not sure if this
> problem was 2.4 kernel specific, or 2.6 kernel specific,
> or signals specific. I think its signals specific.
>
> A web search should yield more info on this. Try googling
> 'signals race condition', and it looks like its a problem
> still.
>
> So it depends on whether your server is running in
> a critical, and secure system, as to whether you want
> to stick with signals.
>
>> I do not know why the function kill_proc_info does not
>> export its symbol within the kernel 2.6.21 .
>> With previous version of the kernel 2.4 and early 2.6.*
>> the kill_proc_info symbol was exported.
>
> If SIGIO is sufficient for you, then just use the driver
> fasync() call-back mechanism. The example code I referred
> to has an example. If its not clear to you, I can
> explain it.
>
> If you're having to modify some corner of the kernel not
> used by many, then I'm sure your solution is not the
> correct one, and you won't get anyone helping you
> when things go wrong.
>
> So, take the experience of others; re-write the server
> to use signals. If the server was well written to start
> with you should be able to call the 'signal handler'
> function after returning from your select() call with
> the handle ready. It shouldn't be that hard.
>
> Come on, you've just returned from holiday, it should
> be no sweat to code up a new server :)
>
> Regards,
> Dave
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12291367
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH v7 0/3] [POWERPC] fsl_soc: add support for fsl_spi
From: Anton Vorontsov @ 2007-08-23 11:33 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070823132421.d2b230af.sfr@canb.auug.org.au>
On Thu, Aug 23, 2007 at 01:24:21PM +1000, Stephen Rothwell wrote:
> Hi Anton,
>
> On Wed, 22 Aug 2007 18:57:32 +0400 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> >
> > + sysclk = *(u32 *)of_get_property(np, "bus-frequency", NULL);
>
> I just cringe everytime I see someone dereference a pointer they got from
> somewhere (effectively) external without checking for NULL.
Actually, sitting at the editor I thought twice before _removing_ NULL
checks, and obviously was wrong with final decision. ;-)
I just knew that there is already many places in fsl_soc that don't
check for NULLs, especially when:
> I realise
> that sometimes "that can't happen" ...
Probably to save some code space. But now I seem to comprehend it: not
checking for NULL properties is not a some kind of rule for fsl_soc,
but exceptions which probably should be fixed someday.
Thanks.
[Not related to this particular answer]
Heh.. honestly speaking, I myself don't like externs I introducing in
the board file. Okay, let's risk, and do whole thing correctly:
placing externs into asm/qe.h, trivial patch that could end up with
long discussion. ;-)
Lucky numbered v7 is following.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH v7 1/3] [POWERPC] QE lib: extern par_io_config_pin and par_io_data_set funcs
From: Anton Vorontsov @ 2007-08-23 11:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070823113349.GA11870@localhost.localdomain>
This is needed to configure and control QE pario pins from the kernel.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
include/asm-powerpc/qe.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index 9d304b1..ad23c58 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -32,6 +32,9 @@
extern void qe_reset(void);
extern int par_io_init(struct device_node *np);
extern int par_io_of_config(struct device_node *np);
+extern int par_io_config_pin(u8 port, u8 pin, int dir, int open_drain,
+ int assignment, int has_irq);
+extern int par_io_data_set(u8 port, u8 pin, u8 val);
/* QE internal API */
int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input);
--
1.5.0.6
^ permalink raw reply related
* [PATCH v7 2/3] [POWERPC] fsl_soc: add support for fsl_spi
From: Anton Vorontsov @ 2007-08-23 11:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070823113349.GA11870@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_soc.c | 87 +++++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_soc.h | 7 +++
2 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 1cf29c9..2f11323 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -24,6 +24,7 @@
#include <linux/platform_device.h>
#include <linux/of_platform.h>
#include <linux/phy.h>
+#include <linux/spi/spi.h>
#include <linux/fsl_devices.h>
#include <linux/fs_enet_pd.h>
#include <linux/fs_uart_pd.h>
@@ -1187,3 +1188,89 @@ err:
arch_initcall(cpm_smc_uart_of_init);
#endif /* CONFIG_8xx */
+
+int __init fsl_spi_init(struct spi_board_info *board_infos,
+ unsigned int num_board_infos,
+ void (*activate_cs)(u8 cs, u8 polarity),
+ void (*deactivate_cs)(u8 cs, u8 polarity))
+{
+ struct device_node *np;
+ unsigned int i;
+ const u32 *sysclk;
+
+ np = of_find_node_by_type(NULL, "qe");
+ if (!np)
+ return -ENODEV;
+
+ sysclk = of_get_property(np, "bus-frequency", NULL);
+ if (!sysclk)
+ return -ENODEV;
+
+ for (np = NULL, i = 1;
+ (np = of_find_compatible_node(np, "spi", "fsl_spi")) != NULL;
+ i++) {
+ int ret = 0;
+ unsigned int j;
+ const void *prop;
+ struct resource res[2];
+ struct platform_device *pdev;
+ struct fsl_spi_platform_data pdata = {
+ .activate_cs = activate_cs,
+ .deactivate_cs = deactivate_cs,
+ };
+
+ memset(res, 0, sizeof(res));
+
+ pdata.sysclk = *sysclk;
+
+ prop = of_get_property(np, "reg", NULL);
+ if (!prop)
+ goto err;
+ pdata.bus_num = *(u32 *)prop;
+
+ prop = of_get_property(np, "mode", NULL);
+ if (prop && !strcmp(prop, "cpu-qe"))
+ pdata.qe_mode = 1;
+
+ for (j = 0; j < num_board_infos; j++) {
+ if (board_infos[j].bus_num == pdata.bus_num)
+ pdata.max_chipselect++;
+ }
+
+ if (!pdata.max_chipselect)
+ goto err;
+
+ ret = of_address_to_resource(np, 0, &res[0]);
+ if (ret)
+ goto err;
+
+ ret = of_irq_to_resource(np, 0, &res[1]);
+ if (ret == NO_IRQ)
+ goto err;
+
+ pdev = platform_device_alloc("mpc83xx_spi", i);
+ if (!pdev)
+ goto err;
+
+ ret = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (ret)
+ goto unreg;
+
+ ret = platform_device_add_resources(pdev, res,
+ ARRAY_SIZE(res));
+ if (ret)
+ goto unreg;
+
+ ret = platform_device_register(pdev);
+ if (ret)
+ goto unreg;
+
+ continue;
+unreg:
+ platform_device_del(pdev);
+err:
+ continue;
+ }
+
+ return spi_register_board_info(board_infos, num_board_infos);
+}
diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
index 04e145b..618d91d 100644
--- a/arch/powerpc/sysdev/fsl_soc.h
+++ b/arch/powerpc/sysdev/fsl_soc.h
@@ -8,5 +8,12 @@ extern phys_addr_t get_immrbase(void);
extern u32 get_brgfreq(void);
extern u32 get_baudrate(void);
+struct spi_board_info;
+
+extern int fsl_spi_init(struct spi_board_info *board_infos,
+ unsigned int num_board_infos,
+ void (*activate_cs)(u8 cs, u8 polarity),
+ void (*deactivate_cs)(u8 cs, u8 polarity));
+
#endif
#endif
--
1.5.0.6
^ permalink raw reply related
* [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1 in QE, register mmc_spi stub
From: Anton Vorontsov @ 2007-08-23 11:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070823113349.GA11870@localhost.localdomain>
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing "spidev"
with "mmc_spi".
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 46 +++++++++++++++++++++++++++++
2 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index e9c332f..1ac0025 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -211,7 +211,7 @@
reg = <4c0 40>;
interrupts = <2>;
interrupt-parent = <&qeic>;
- mode = "cpu";
+ mode = "cpu-qe";
};
spi@500 {
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index e021b08..7ddb527 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -15,6 +15,7 @@
*/
#include <linux/pci.h>
+#include <linux/spi/spi.h>
#include <asm/of_platform.h>
#include <asm/time.h>
@@ -22,6 +23,7 @@
#include <asm/udbg.h>
#include <asm/qe.h>
#include <asm/qe_ic.h>
+#include <sysdev/fsl_soc.h>
#include "mpc83xx.h"
@@ -32,6 +34,50 @@
#define DBG(fmt...)
#endif
+static void mpc83xx_spi_activate_cs(u8 cs, u8 polarity)
+{
+ pr_debug("%s %d %d\n", __func__, cs, polarity);
+ par_io_data_set(3, 13, polarity);
+}
+
+static void mpc83xx_spi_deactivate_cs(u8 cs, u8 polarity)
+{
+ pr_debug("%s %d %d\n", __func__, cs, polarity);
+ par_io_data_set(3, 13, !polarity);
+}
+
+static struct spi_board_info mpc832x_spi_boardinfo = {
+ .bus_num = 0x4c0,
+ .chip_select = 0,
+ .max_speed_hz = 50000000,
+ /*
+ * XXX: This is spidev (spi in userspace) stub, should
+ * be replaced by "mmc_spi" when mmc_spi will hit mainline.
+ */
+ .modalias = "spidev",
+};
+
+static int __init mpc832x_spi_init(void)
+{
+ if (!machine_is(mpc832x_rdb))
+ return 0;
+
+ par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
+ par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
+ par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
+ par_io_config_pin(3, 3, 2, 0, 1, 0); /* SPI1 SEL, I */
+
+ par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS, O */
+ par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
+ par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */
+
+ return fsl_spi_init(&mpc832x_spi_boardinfo, 1,
+ mpc83xx_spi_activate_cs,
+ mpc83xx_spi_deactivate_cs);
+}
+
+device_initcall(mpc832x_spi_init);
+
/* ************************************************************************
*
* Setup the architecture
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH 2/2] [POWERPC] Size swapper_pg_dir correctly
From: Kumar Gala @ 2007-08-23 13:17 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20070823161351.2a5f8096.sfr@canb.auug.org.au>
On Aug 23, 2007, at 1:13 AM, Stephen Rothwell wrote:
> On Wed, 22 Aug 2007 22:26:35 -0500 Kumar Gala
> <galak@kernel.crashing.org> wrote:
>>
>>> +#ifdef CONFIG_PPC64
>>> + DEFINE(PGD_TABLE_SIZE, PGD_TABLE_SIZE);
>>> +#endif
>>
>> Why limit this to ppc64? The cleanup should be reasonable for all
>> ppc.
>
> Because PGD_TABLE_SIZE only exists for ppc64 :-) for ppc32 the
> swapper_pg_dir will always be 1 page, right?
No, it can be 2 pages if we do > 32-bit physical on 44x/fsl_booke.
> So we could have
> #define PGD_TABLE_SIZE PAGE_SIZE
> for 32 bit and then go around and change the swapper_pg_dir's, but
> that
> would be a separate patch.
- k
^ permalink raw reply
* Flash paritioning and JFFS2
From: Mirek23 @ 2007-08-23 13:36 UTC (permalink / raw)
To: linuxppc-embedded
Dear All,
I am running linux 2.6.21 (by Grant) on the ppc405 which is build in
Virtex-4 of Avnet (xlinx ml403 like) evaluation board. The Avnet board has
the 4 MB of NOR Flash (Intel TE28F640) . I just wanted to make use of the
Flash to store
u-boot, linux kernel and some config files.
To do so I wanted first to partition Flash to three partitions:
- U-Boot
- Linux-kernel
- JFFS2 (for some config files)
Could someone advice me how to configure Linux kernel to make use of the
Flash (with above mentioned partitions and JFFS2.
The information which I have collected is as following that I have to:
enable in kernel:
Device Drivers->Memory Technology Devices (MTD)
File Systems -> Miscellaneous file systems -> JFFS2
I do not know however which specific options to enable for MTD/JFFS2 since
it has many sub options.
I do not no also where to place:
-the partition information (which I have mentioned above)
-the start (0xFF800000) and end (0xFFBFFFFF) physical location of my Flash
memory.
My aim is to mount (after booting Linux) the JFFS2 partition to store some
config data.
Best Regards and thank you in advance for any hint on that
Mirek
--
View this message in context: http://www.nabble.com/Flash-paritioning-and-JFFS2-tf4317566.html#a12293748
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Flash paritioning and JFFS2
From: Michael Brian Willis @ 2007-08-23 16:08 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <12293748.post@talk.nabble.com>
On Thu, 2007-08-23 at 06:36 -0700, Mirek23 wrote:
> Could someone advice me how to configure Linux kernel to make use of the
> Flash (with above mentioned partitions and JFFS2.
The Denx U-boot and Linux Guide (DULG) will tell you how to configure
the kernel for MTD devices and will give some good general information:
http://www.denx.de/wiki/view/DULG/FlashFilesystemsMTD
> I do not know however which specific options to enable for MTD/JFFS2 since
> it has many sub options.
The following post has some relevant information for your setup:
http://osdir.com/ml/linux.uclinux.devel/2005-12/msg00130.html
> I do not know also where to place:
> -the partition information (which I have mentioned above)
The partition information probably should go in a file that you create
for your board located at "drivers/mtd/maps/<your_file>.c"
> -the start (0xFF800000) and end (0xFFBFFFFF) physical location of my Flash
> memory.
I think this information just needs to be defined in your board's .h
file in u-boot. I don't think you need to specify this in any linux
config files.
I hope this info helps.
Regards,
Michael Willis
Applied Research Labs - University of Texas
willis@arlut.utexas.edu
^ 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