SRAM @ FSL eLBC
Hi, I'd like to use a SRAM device (512K*8) connected to a MPC8377 localbus. What's a decent way to do this (mmap'ed access) running v2.6.34 ? Is platform RAM (drivers/mtd/maps/plat-ram.c) a good starting point ? Any hints are welcome. -- Regards, Andre MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI DMA to user mem on mpc83xx
Ira, On Mon, May 23, 2011 at 11:12:41AM +0200, Andre Schwarz wrote: Ira, we have a pretty old PCI device driver here that needs some basic rework running on 2.6.27 on several MPC83xx. It's a simple char-device with give me some data implemented using read() resulting in zero-copy DMA to user mem. There's get_user_pages() working under the hood along with SetPageDirty() and page_cache_release(). Main goal is to prepare a sg-list that gets fed into a DMA controller. I wonder if there's a more up-to-date/efficient and future proof scheme of creating the mapping. Could you provide some pointers or would you stick to the current scheme ? This scheme is the best you'll come up with for zero-copy IO. I used get_user_pages_fast(), but otherwise my implementation was the same. These interfaces should be fairly future proof. excellent - thanks. Will stick to it then ... In the end, I realized that most of my transfers were 4 bytes in length, and zero copy IO was a waste of effort. I decided to use mmap instead. I'm using 98% page sized (4KiB) scatter gather transfers summing up to ~80MiB/sec sustained throughput. Cheers, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI DMA to user mem on mpc83xx
David, we have a pretty old PCI device driver here that needs some basic rework running on 2.6.27 on several MPC83xx. It's a simple char-device with give me some data implemented using read() resulting in zero-copy DMA to user mem. There's get_user_pages() working under the hood along with SetPageDirty() and page_cache_release(). Does that dma use the userspace virtual address, or the physical address - or are you remapping the user memory into kernel address space. no mapping at all AFAIK. I'm using get_user_pages() followed by allocation of a struct scatterlist being filled with sg_set_page(). After the transfer the pages are marked dirty using SetPageDirty(). If the memory is remapped into the kernel address space, the cost of the mmu and tlb operations (especially on MP systems) is such that a dma to kernel memory followed by copyout/copytouser may well be faster! no mapping. That may even be the case even if the dma is writing to the user virtual (or physical) addresses when it is only necessary to ensure the memory page is resident and that the caches are coherent. All I need is physical addresses of user mem. Since the allocating user driver is using mlock() and there's no swap I expect to be safe ... is this a stupid assumption ? In any case the second copy is probably far faster than the PCI one! huh - I observed memcpy() to be very expensive (at least on 83xx PowerPC). I've recently written driver that supports a pread/pwrite interface to the memory windows on a PCIe card. It was important to use dma for the PCIe transfers (to get a sensible transfer size). I overlapped the copyin/copyout with the next dma transfer. The dma's are fast enough that it is worth spinning waiting for completion - but slow enough to make the overlapped operation worthwhile (same speed as a single word pio transfer). Thanks for your feedback. Cheers, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PCI DMA to user mem on mpc83xx
Ira, we have a pretty old PCI device driver here that needs some basic rework running on 2.6.27 on several MPC83xx. It's a simple char-device with give me some data implemented using read() resulting in zero-copy DMA to user mem. There's get_user_pages() working under the hood along with SetPageDirty() and page_cache_release(). Main goal is to prepare a sg-list that gets fed into a DMA controller. I wonder if there's a more up-to-date/efficient and future proof scheme of creating the mapping. Could you provide some pointers or would you stick to the current scheme ? Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to define an I2C-to-SPI bridge device ?
On 03/25/2011 10:28 AM, Andre Schwarz wrote:
Grant, Anton,
got it.
providing modalis = spidev within spi_board_info works like a charme ...
Cheers,
André
we're about to get new MPC8377 based hardware with various
peripherals.
There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm
not sure
how to define a proper dts...
Of course it's an easy thing creating 2 child nodes on the CPU's I2C
device - but how can I represent the created SPI bus ?
Um.. the same as the other SPI buses? I.e.
i2c-controller { /* SOC I2C controller */
spi-controller { /* The I2C-to-SPI bridge */
spi-device@0 {
};
spi-device@1 {
};
};
};
ok , thanks - looks straight forward.
Is this any more than plain definition, i.e. will this trigger any I2C
or SPI device registration/linking ?
Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to
be an
I2C slave or an SPI host driver ?
It should be an I2C driver that registers an SPI master (i.e.
calls spi_alloc_master() and spi_register_master()).
hmm - ok. Will have to do it manually then ...
Yes, but this is the case for non-of drivers too. The i2c to spi
device driver must always create (and trigger population of) the spi
bus instance.
I've kicked that I2C-to-SPI stuff completely because it's been too slow.
We've connected the SPI busses to the FPGA controlling almost
everything now.
Unfortunately there are some questions left :
Following Anton's suggestion I've had a look at /drivers/mfd (sm501.c)
and implemented a pci driver for the FPGA using
subdevices for additional functionality it exports - besides others we
now have 2 SPI masters.
For both SPI masters I have created and registered a platform_device.
pdev-dev is then fed into spi_alloc_master() and the resulting master
goes into spi_register_master().
master-bus_num is set to 0 and 1, i.e. no dynamic numbering.
master-chipselect = 8;
Since I can probe the SPI device using FPGA intrinsic information I
decided to register the client
devices on runtime using a struct spi_board_info which is fed into
spi_new_device().
The current design has 2 clients on SPI-0 and 5 clients on SPI-1.
static struct spi_board_info mergerbox_spi_boardinfo[] = {
{ .bus_num = 0,
.chip_select = 0,
.max_speed_hz = 420, },
{ .bus_num = 0,
.chip_select = 1,
.max_speed_hz = 420, },
{ .bus_num = 1,
.chip_select = 0,
.max_speed_hz = 420, },
.
After loading my module I get :
# ls /sys/devices/platform/AlteraSPI.0/
/sys/devices/platform/AlteraSPI.0/modalias
/sys/devices/platform/AlteraSPI.0/spi0.0/
/sys/devices/platform/AlteraSPI.0/spi0.1/
/sys/devices/platform/AlteraSPI.0/spi_master/
/sys/devices/platform/AlteraSPI.0/subsystem/
/sys/devices/platform/AlteraSPI.0/uevent
# ls /sys/devices/platform/AlteraSPI.1/
/sys/devices/platform/AlteraSPI.1/modalias
/sys/devices/platform/AlteraSPI.1/spi1.0/
/sys/devices/platform/AlteraSPI.1/spi1.1/
/sys/devices/platform/AlteraSPI.1/spi1.2/
/sys/devices/platform/AlteraSPI.1/spi1.3/
/sys/devices/platform/AlteraSPI.1/spi1.4/
/sys/devices/platform/AlteraSPI.1/spi_master/
/sys/devices/platform/AlteraSPI.1/subsystem/
/sys/devices/platform/AlteraSPI.1/uevent
What I'm missing are the /dev/spi* entries.
There's also a spi_mpc8xxx driver using the CPU's SPI controller.
It is configured by dts (2 devices) and uses dynamic bus numbering:
# ls /sys/bus/spi/devices/
spi0.0 spi1.0 spi1.2 spi1.4 spi32766.1
spi0.1 spi1.1 spi1.3 spi32766.0
This devices are processed by spidev and proper entries are created
ready for use :
# ls /dev/spi*
/dev/spidev32766.0 /dev/spidev32766.1
Am I missing somehting obvious ?
Since there's no driver registration we don't have a probe function -
is this a problem regarding device binding ?
Do I need to use the .modalias in struct spi_board_info ?
Any help is welcome.
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to define an I2C-to-SPI bridge device ?
Grant, Anton,
we're about to get new MPC8377 based hardware with various peripherals.
There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
how to define a proper dts...
Of course it's an easy thing creating 2 child nodes on the CPU's I2C
device - but how can I represent the created SPI bus ?
Um.. the same as the other SPI buses? I.e.
i2c-controller { /* SOC I2C controller */
spi-controller { /* The I2C-to-SPI bridge */
spi-device@0 {
};
spi-device@1 {
};
};
};
ok , thanks - looks straight forward.
Is this any more than plain definition, i.e. will this trigger any I2C
or SPI device registration/linking ?
Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
I2C slave or an SPI host driver ?
It should be an I2C driver that registers an SPI master (i.e.
calls spi_alloc_master() and spi_register_master()).
hmm - ok. Will have to do it manually then ...
Yes, but this is the case for non-of drivers too. The i2c to spi device driver
must always create (and trigger population of) the spi bus instance.
I've kicked that I2C-to-SPI stuff completely because it's been too slow.
We've connected the SPI busses to the FPGA controlling almost everything
now.
Unfortunately there are some questions left :
Following Anton's suggestion I've had a look at /drivers/mfd (sm501.c)
and implemented a pci driver for the FPGA using
subdevices for additional functionality it exports - besides others we
now have 2 SPI masters.
For both SPI masters I have created and registered a platform_device.
pdev-dev is then fed into spi_alloc_master() and the resulting master
goes into spi_register_master().
master-bus_num is set to 0 and 1, i.e. no dynamic numbering.
master-chipselect = 8;
Since I can probe the SPI device using FPGA intrinsic information I
decided to register the client
devices on runtime using a struct spi_board_info which is fed into
spi_new_device().
The current design has 2 clients on SPI-0 and 5 clients on SPI-1.
static struct spi_board_info mergerbox_spi_boardinfo[] = {
{ .bus_num = 0,
.chip_select = 0,
.max_speed_hz = 420, },
{ .bus_num = 0,
.chip_select = 1,
.max_speed_hz = 420, },
{ .bus_num = 1,
.chip_select = 0,
.max_speed_hz = 420, },
.
After loading my module I get :
# ls /sys/devices/platform/AlteraSPI.0/
/sys/devices/platform/AlteraSPI.0/modalias
/sys/devices/platform/AlteraSPI.0/spi0.0/
/sys/devices/platform/AlteraSPI.0/spi0.1/
/sys/devices/platform/AlteraSPI.0/spi_master/
/sys/devices/platform/AlteraSPI.0/subsystem/
/sys/devices/platform/AlteraSPI.0/uevent
# ls /sys/devices/platform/AlteraSPI.1/
/sys/devices/platform/AlteraSPI.1/modalias
/sys/devices/platform/AlteraSPI.1/spi1.0/
/sys/devices/platform/AlteraSPI.1/spi1.1/
/sys/devices/platform/AlteraSPI.1/spi1.2/
/sys/devices/platform/AlteraSPI.1/spi1.3/
/sys/devices/platform/AlteraSPI.1/spi1.4/
/sys/devices/platform/AlteraSPI.1/spi_master/
/sys/devices/platform/AlteraSPI.1/subsystem/
/sys/devices/platform/AlteraSPI.1/uevent
What I'm missing are the /dev/spi* entries.
There's also a spi_mpc8xxx driver using the CPU's SPI controller.
It is configured by dts (2 devices) and uses dynamic bus numbering:
# ls /sys/bus/spi/devices/
spi0.0 spi1.0 spi1.2 spi1.4 spi32766.1
spi0.1 spi1.1 spi1.3 spi32766.0
This devices are processed by spidev and proper entries are created
ready for use :
# ls /dev/spi*
/dev/spidev32766.0 /dev/spidev32766.1
Am I missing somehting obvious ?
Since there's no driver registration we don't have a probe function - is
this a problem regarding device binding ?
Do I need to use the .modalias in struct spi_board_info ?
Any help is welcome.
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC831x (and others?) NAND erase performance improvements
Scott, do you think this issue also applies to MPC8377 ? I'm in the middle of a small redesign for series production and would like not to miss a thing. We have Nand, Nor and MRAM connected to LBC. Since RFS is running from NAND and we use the MRAM as a non-volatile SRAM I'd like to avoid being hit by this issue. Any comments from your side ? Regards, André On Wed, 8 Dec 2010 22:26:59 +0100 Joakim Tjernlundjoakim.tjernl...@transmode.se wrote: Scott Woodscottw...@freescale.com wrote on 2010/12/08 21:25:51: On Wed, 8 Dec 2010 21:11:08 +0100 Joakim Tjernlundjoakim.tjernl...@transmode.se wrote: Scott Woodscottw...@freescale.com wrote on 2010/12/08 20:59:28: On Wed, 8 Dec 2010 20:57:03 +0100 Joakim Tjernlundjoakim.tjernl...@transmode.se wrote: Can you think of any workaround such as not connecting the BUSY pin at all? Maybe connect the busy pin to a gpio? Is BUSY required for sane operation or it an optimization? You could probably get away without it by inserting delays if you know the chip specs well enough. Urgh, that does not feel like a good solution. No, but you asked if it could be done, and if it was just a performance issue. :-) Is there any risk that the NAND device will drive the LB and corrupt the bus for other devices? I think the only thing the NAND chip should be driving is the busy pin, OK, good. What function is actually lost if one uses an GPIO instead of BUSY? Not much, if you enable interrupts on the GPIO pin. The driver would have to be reworked a bit, of course. You think Freescale could test and validate a GPIO solution? I don't think we will be very happy to design our board around an unproven workaround. Ask your sales/support contacts. An even better workaround would be if one could add logic between the NAND and the CPU which would compensate for this defect without needing special SW fixes. The problem with that is when would you assert the chipselect again to check if it's done? Current SW depends on being able to tell the LBC to interrupt (or take other action) when busy goes away. I suppose you could poll with status reads, which could at least be preempted if you've got something higher priority to do with the LBC. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to define an I2C-to-SPI bridge device ?
Anton,
we're about to get new MPC8377 based hardware with various peripherals.
There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
how to define a proper dts...
Of course it's an easy thing creating 2 child nodes on the CPU's I2C
device - but how can I represent the created SPI bus ?
Um.. the same as the other SPI buses? I.e.
i2c-controller { /* SOC I2C controller */
spi-controller { /* The I2C-to-SPI bridge */
spi-dev...@0 {
};
spi-dev...@1 {
};
};
};
ok , thanks - looks straight forward.
Is this any more than plain definition, i.e. will this trigger any I2C
or SPI device registration/linking ?
Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
I2C slave or an SPI host driver ?
It should be an I2C driver that registers an SPI master (i.e.
calls spi_alloc_master() and spi_register_master()).
hmm - ok. Will have to do it manually then ...
I still wonder how to make the driver arch-generic *and* of-capable.
Do we need a generic I2C slave driver that can be probed along with an
of glue driver or should the of-binding be part of a single device
driver ?
Sorry for the dumb questions - looks like I expected a little too much
functionality already existing.
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner,
Hans-Joachim Reich
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC5200 PCI Issues
Tobias,
are you starting with 2.6.28 or are you upgrading ?
My system runs very fine with 2.6.27
Tobias Knutsson wrote:
I am currently trying to get an MPC5200-based board to run Linux
2.6.28. Most of the devices are working, however i have some issues
with the PCI-bus. More precisely, the issue is that all of
the cards' IO-regions are mapped to address 0x0.
In my device tree I have the following:
p...@fd00 {
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
device_type = pci;
compatible = fsl,mpc5200b-pci,fsl,mpc5200-pci;
reg = 0xfd00 0x100;
interrupt-map-mask = 0xf800 0 0 7;
interrupt-map = 0xb000 0 0 1 mpc5200_pic 0 0 3 // MPC5200
0xb000 0 0 2 mpc5200_pic 0 0 3
0xb000 0 0 3 mpc5200_pic 0 0 3
0xb000 0 0 4 mpc5200_pic 0 0 3
What's this ? Is the MPC5200 interrupting itself ?
0xb800 0 0 1 mpc5200_pic 1 1 3 // c64x0
0xb800 0 0 2 mpc5200_pic 1 1 3
0xb800 0 0 3 mpc5200_pic 1 1 3
0xb800 0 0 4 mpc5200_pic 1 1 3
Have you connected 4 IRQ lines to each c64x device ?
0xc000 0 0 1 mpc5200_pic 1 1 3 // c64x1
0xc000 0 0 2 mpc5200_pic 1 1 3
0xc000 0 0 3 mpc5200_pic 1 1 3
0xc000 0 0 4 mpc5200_pic 1 1 3
0xc800 0 0 1 mpc5200_pic 1 1 3 // c64x2
0xc800 0 0 2 mpc5200_pic 1 1 3
0xc800 0 0 3 mpc5200_pic 1 1 3
0xc800 0 0 4 mpc5200_pic 1 1 3
0xd000 0 0 1 mpc5200_pic 1 1 3 // c64x3
0xd000 0 0 2 mpc5200_pic 1 1 3
0xd000 0 0 3 mpc5200_pic 1 1 3
0xd000 0 0 4 mpc5200_pic 1 1 3
0xd800 0 0 1 mpc5200_pic 1 1 3 // c64x4
0xd800 0 0 2 mpc5200_pic 1 1 3
0xd800 0 0 3 mpc5200_pic 1 1 3
0xd800 0 0 4 mpc5200_pic 1 1 3;
I'm using an external FPGA and an e1000 NIC connectedt to IRQ2 and IRQ3 :
interrupt-map = 0x5800 0 0 1 mpc5200_pic 1 2 3
0x5000 0 0 1
mpc5200_pic 1 3 3;
clock-frequency = 0x1e84800; //0; // From boot loader
interrupts = 2 8 0 2 9 0 2 10 0;
interrupt-parent = mpc5200_pic;
bus-range = 0 0;
ranges = 0x0200 0 0x5000 0x5000 0 0x1000
0x0100 0 0x 0x6000 0 0x0100;
};
I'm using a 3 liner :
ranges = 0x4200 0 0x8000 0x8000 0 0x2000
0x0200 0 0xa000 0xa000 0 0x1000
0x0100 0 0x 0xb000 0 0x0100;
The cards' memory regions are mapped out fine to different addresses
in the 0x5000-0x6000 range. However, the IO regions are all mapped
to zero.
Are you c64x devices responding properly ? Is IO access enabled in the
PCI command register ?
Are they announcing a reasonable window ? How man KBytes ?
Do you have any idea on what could be wrong or in which direction I
should be looking?
Hopefully something is useful to you.
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim
Reich
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add support for the digsy MTC board.
Grant Likely wrote: On Mon, Feb 2, 2009 at 4:58 PM, Wolfgang Denk w...@denx.de wrote: Dear Grzegorz Bernacki, In message 49872268.10...@semihalf.com you wrote: We also had this kind of problem - after feeding some nfs options it worked : rsize=8192,wsize=8192,soft,intr,tcp,nolock it seems that it helps. Can you please find out which of these changes is the relevant part? Probably the ,tcp bit g. yes - obviously the retry counter of lost udp packets is pretty small inside the nfs client or server. The problem only occurs when there's fairly high traffic and/or low performance switches are used and UDP packets get lost frequently. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add support for the digsy MTC board.
Grzegorz Bernacki wrote:
Grant Likely wrote:
+/dts-v1/;
+
+/ {
+ model = mtc,digsy;
+ compatible = mtc,digsy;
This should be something like: intercontrol,digsy-mtc. Compatible
values should be in the form vendor,model.
ok, I will change it
+ mpc5200_pic: interrupt-control...@500 {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ device_type = interrupt-controller;
Drop device_type here.
ok, I will drop it
+ compatible = fsl,mpc5200b-pic,fsl,mpc5200-pic;
+ reg = 0x500 0x80;
+ };
+
+ ti...@600 { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ cell-index = 0;
Drop cell-index on all the timer nodes. If you compare this file with
the current cm5200.dts in mainline then you'll see the properties that
you can drop.
Otherwise the device tree looks pretty good.
diff --git a/arch/powerpc/configs/52xx/digsy_mtc_defconfig
b/arch/powerpc/configs/52xx/digsy_mtc_defconfig
new file mode 100644
index 000..ad70d5b
--- /dev/null
+++ b/arch/powerpc/configs/52xx/digsy_mtc_defconfig
I would like to have support for following devices in defconfig for digsy:
- LXT PHY
- RTC DS1337
- EEPROM AT24
- MTD partitioning based on OF description
If you dont mind I can add them to generic mpc5200 defconfig, otherwise
I think that separate defconfig is needed.
Do you *really* need your own defconfig for the digsy_mtc. I've
grudgingly accepted them for other boards under the argument that the
defconfig reflects a specific application of the board. However, I'd
much rather see the digsy added to the multiplatform
mpc5200_defconfig, especially considering that the MTC looks like it's
supposed to be a general purpose platform.
There is a lot of direct copy/paste from the lite5200.c board file,
but the big scary warning comment about not duplicating this code was
deleted in the copy (so I know you saw it). Is Semihalf responsible
for the U-Boot port to the digsy-mtc? If so then please fix the
port_config and clock settings in u-boot.
I will update port config and clock settings in u-boot and use mpc5200_simple
instead of creating a new file for digsy.
BTW,
I noticed that there are some problems with mounting file system
over NFS on Linux-2.6.29-rc3, I see following messages:
...
[ 339.813807] nfs: server 192.168.1.1 not responding, still trying
[ 339.832144] nfs: server 192.168.1.1 OK
...
I haven't noticed in on Linux-2.6.29-rc2. Is there any known problem?
We also had this kind of problem - after feeding some nfs options it
worked :
rsize=8192,wsize=8192,soft,intr,tcp,nolock
Cheers,
Andre
regards,
Grzesiek
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim
Reich
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/5200: Bugfix for PCI mapping of memory and IMMR
Matt Sealey wrote: On Mon, Jan 26, 2009 at 10:34 PM, Grant Likely grant.lik...@secretlab.ca wrote: From: Grant Likely grant.lik...@secretlab.ca This patch ensures that memory gets properly mapped into the PCI address space. Without this patch, the memory window BAR is left at whatever value happened to be loaded into the BAR when Linux was booted. Without this patch, memory could end up getting mapped at any of the 1G address boundaries instead of at '0' where Linux expects it. Similarly, this patch also ensures that the internally memory mapped registers (IMMR) are mapped to the correct PCI address range. Without this patch, PCI appears to work correctly until a PCI device is inserted which DMAs into memory. Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- This is a bugfix that I intend to merge into 2.6.29 and once it is mainlined get it added to the stable queue. If you have a 5200 system, please test and make sure it works for you. Thanks g. arch/powerpc/platforms/52xx/mpc52xx_pci.c | 24 ++-- 1 files changed, 10 insertions(+), 14 deletions(-) This doesn't affect Efika, right? What's the expected impact and how come nobody tried a DMA-capable PCI card in an MPC5200B board before? :) We're running a MPC5200B based board with an external FPGA pumping as much data into the CPU's memory as possible using scatter-gather DMA. No problems so far ... besides the lousy PCI target performance of the 5200, of course. Of course we've been always running latest u-boot. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MicroSD (SPI mode) support in Linux-2.6.26-1
Sai Amruta wrote: Hi All, I am using linux-2.6.26 on MPC8567 and microSD is connected through SPI interface. Is the existing mmc driver supports microSD? yes - it's working perfectly fine on my MPC8343. Even with SDHC cards ;-) cheers, Andre -- --Amru ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MicroSD (SPI mode) support in Linux-2.6.26-1
Wolfgang Wegner wrote:
Hi Andre,
On Fri, Jan 23, 2009 at 01:43:47PM +0100, Andre Schwarz wrote:
Sai Amruta wrote:
Hi All,
I am using linux-2.6.26 on MPC8567 and microSD is connected through
SPI interface.
Is the existing mmc driver supports microSD?
yes - it's working perfectly fine on my MPC8343.
Even with SDHC cards ;-)
that's great to hear - is there anything like a HOWTO on how to set
this up on top of the SPI driver (probably involving some custom GPIO
stuff for card and WP detection) out there?
I tried to but did not get it to work on MCF53xx (uClinux 2.6.23-uc0)
and probably did not find the right search strings either.
Regards,
Wolfgang
I'm sorry - no README.
All I can do is provide the info how it works for me :
platform code : provide init and chips select functions.
static void mvblm7_spi_activate_cs(u8 cs, u8 polarity)
{
u32 data = in_be32( mvblm7_gpio + 2 );
if (polarity)
out_be32( mvblm7_gpio + 2, data | MVBLM7_MMC_CS );
else
out_be32( mvblm7_gpio + 2, data ~MVBLM7_MMC_CS );
}
static void mvblm7_spi_deactivate_cs(u8 cs, u8 polarity)
{
u32 data = in_be32( mvblm7_gpio + 2 );
if (!polarity)
out_be32( mvblm7_gpio + 2, data | MVBLM7_MMC_CS );
else
out_be32( mvblm7_gpio + 2, data ~MVBLM7_MMC_CS );
}
static struct mmc_spi_platform_data mvblm7_mmc_pdata = {
.ocr_mask = MMC_VDD_33_34,
};
static struct spi_board_info mvblm7_spi_boardinfo = {
.bus_num = 0x7000,
.chip_select = 0,
.max_speed_hz = 5000,
.modalias = mmc_spi,
.platform_data = mvblm7_mmc_pdata,
};
static int __init mvblm7_spi_init(void)
{
return fsl_spi_init(mvblm7_spi_boardinfo, 1,
mvblm7_spi_activate_cs,
mvblm7_spi_deactivate_cs);
}
machine_device_initcall(mvblm7, mvblm7_spi_init);
Kernel config :
CONFIG_MMC=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_MMC_SPI=m
and of course the driver for your SPI controller ...
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_MPC83xx=y
I've had no time to set up hotplug/card detect features.
Actually my system boots with card plugged in and and I do a insmod
mmc_spi.ko - card gets probed.
-mount -t vfat /dev/mmcblk0p1 /mnt/mmc
hope this helps.
cheers,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim
Reich
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MicroSD (SPI mode) support in Linux-2.6.26-1
Wolfgang Wegner wrote: Hi Andre, On Fri, Jan 23, 2009 at 01:43:47PM +0100, Andre Schwarz wrote: Sai Amruta wrote: Hi All, I am using linux-2.6.26 on MPC8567 and microSD is connected through SPI interface. Is the existing mmc driver supports microSD? yes - it's working perfectly fine on my MPC8343. Even with SDHC cards ;-) that's great to hear - is there anything like a HOWTO on how to set this up on top of the SPI driver (probably involving some custom GPIO stuff for card and WP detection) out there? I tried to but did not get it to work on MCF53xx (uClinux 2.6.23-uc0) and probably did not find the right search strings either. Regards, Wolfgang Wolfgang, of course I forgot the most important messages ... ;-) mvBL-M7 insmod /modules/mmc_spi.ko mvBL-M7 dmesg -c mmc_spi spi28672.0: SD/MMC host mmc0, no DMA, no WP, no poweroff mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new SD card on SPI mmcblk0: mmc0: SD02G 1921024KiB mmcblk0: p1 mvBL-M7 mount /mnt/mmc/ mvBL-M7 ls /mnt/mmc/ TestApp.JPG do TestCSharpApp.exe mvBlueCOUGAR.msi autostart mvPPC_6XX-NAND-20081010-0946.tgz distribution.zip uInitrd.mvblm7_nova mvBL-M7 cheers, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: eth1: Could not attach to PHY on MPC8349e-MITX
Timur, is it possible that the PHY adress doesn't match the one specified in the dts ? regards, Andre Timur Tabi schrieb: The Freescale MPC8349e-MITX reference board has two TSECs, the second of which (eth1) is attached to a Vitesse 7385 5-port switch. Using the latest U-Boot, Kernel, and device tree, I cannot bring up eth1. When I try, I get this message: [EMAIL PROTECTED] root]# ifconfig eth1 up 0:01 not found eth1: Could not attach to PHY SIOCSIFFLAGS: No such device Unfortunately, I don't even know what this means. I believe my network configuration is correct. Here's what ifconfig says about eth1: eth1 Link encap:Ethernet HWaddr 00:E0:0C:00:8C:02 inet addr:192.168.2.141 Bcast:192.168.255.255 Mask:255.255.0.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Base address:0x4000 eth1 does work in U-boot, so I know it can be made to work (and I know the 7385's firmware is uploaded), I just don't know what needs to be done in Linux. MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: eth1: Could not attach to PHY on MPC8349e-MITX
Timur Tabi schrieb:
Andre Schwarz wrote:
Timur,
is it possible that the PHY adress doesn't match the one specified in
the dts ?
What part of the DTS contains the PHY address? I have this:
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 0x24520 0x20;
/* Vitesse 8201 */
phy1c: [EMAIL PROTECTED] {
interrupt-parent = ipic;
interrupts = 18 0x8;
reg = 0x1c;
device_type = ethernet-phy;
};
};
enet1: [EMAIL PROTECTED] {
cell-index = 1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 0x25000 0x1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 35 0x8 36 0x8 37 0x8;
phy-connection-type = mii;
interrupt-parent = ipic;
Your PHY is not on the MDIO bus, i.e. can not be programmed or queried.
Maybe your kernel lacks the mdio-less configuration ?
/* Vitesse 7385 isn't on the MDIO bus */
fixed-link = 1 1 1000 0 0;
linux,network-index = 1;
};
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
i2c-mpc clocking scheme
All, is anybody working on some improvements regarding configurable I2C frequency inside the i2c-mpc driver ? If not - would anybody be intersted in getting this done, i.e. configurable via device tree ? regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
Timur Tabi schrieb: On Thu, Nov 27, 2008 at 9:00 AM, Andre Schwarz [EMAIL PROTECTED] wrote: All, is anybody working on some improvements regarding configurable I2C frequency inside the i2c-mpc driver ? If not - would anybody be intersted in getting this done, i.e. configurable via device tree ? Maybe I'm missing something, but U-Boot configures the I2C bus speed. It does this because the algorithm is specific to the SOC itself. For example, the 8544 is different from the 8548. It would be a mess to duplicate this code in the kernel. You're right regarding U-Boot, but the i2c-mpc driver overwrites the frequency divider register on all chips. I'm not happy with a fixed 0x3f @ MPC5200 which results in 65kHz ... :-( Have a look at line 163 in drivers/i2c/busses/i2c-mpc.c MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200B: Trouble with config pins
Jürgen, Have a look at the manual chapter 4 (=Reset + Config). SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware reset. Looks like you should make use of the SRESET and trigger HRESET accordingly. I could solve this with _not_ using the internal watchdog but an external one (TPS3828), i.e. watchdog timeouts and reboots are always issued by PORESET. regards, Andre Juergen Beisert schrieb: Hi all, we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B CPU. These pins act as the interface to an external phy and also act as configurations pins to configure the size of the flash and other things. While the reset is active these pins should be in their high impedance state and the externally connected pull down resistors should define wire's voltage level. With the rising edge of the reset signal these levels will be latched into internal config registers. We are in trouble when we want to reboot the system (also watchdog based) or the internal watchdog barks and generates the CPU internal reset signal. In these cases these config pins will not change their level! So the wrong settings are latched in and our CPU is dead (misconfigured), sometimes a second reset helps, but most of the time only power cycling helps. What we see is: - at the pins ETH_0 and ETH_3 (both are output only, when used for ethernet) * With an external 10k pulldown these lines never change their 3.3V level even if the reset is active! * With an external 1k pulldown these lines change their 3.3V level down to something about 2.5V when the falling edge of the reset signal occurs. * This level decreases slowly to 1.2V in about 1.2ms and than a falling edge to 0V occures. Problem here is, the internal watchdog's generated reset signal is much shorter, so the rising edge of this reset signal also latches in the wrong settings and the CPU is dead. Some other things we see. A reset while: - a running tftp command in U-Boot with disconnected network - system is always dead - a running tftp command in U-Boot with connected network - system restarts We can see in this case, the ETH_0 and ETH_3 are switching to low level *immediatly* with the falling edge of the reset signal - an activated interface (ifconfig up) in Linux with *disconnected* network - system is always dead - an activated interface (ifconfig up) in Linux with *connected* network - system is always dead Does anybody see a behaviour like ours on his/her MPC5200B based system? Does anybody have an idea what the difference between U-Boot und Linux could be? Bug? Feature? Regards, Juergen MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IRQ2-4 number to use on mpc83xx?
I can only tell how I do on MPC834x : Table 8-6. IVEC/CVEC/MVEC Field Definition Interrupt ID Number Interrupt Meaning 17 IRQ1 18 IRQ2 19 IRQ3 20 IRQ4 21 IRQ5 22 IRQ6 23 IRQ7 48 IRQ0 Given this I can use this dts section for PCI devices connected @ IRQ0 and IRQ1 interrupt-map = 0x5800 0 0 1 ipic 0x30 0x8 0x6000 0 0 1 ipic 0x11 0x8 0x6000 0 0 2 ipic 0x11 0x8; You should be able to use IRQ-Nr 18-20 for IRQ2-4. regards, Andre Tjernlund schrieb: I am trying to figure out what IRQ number I should use for external IRQ pins IRQ2-4. Can somebody please drop me a note on how the IRQ numbering works? Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] Add MPC5200B base board mvBC-P
The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit ethernet
controller (using e1000). It's just another MPC5200_simple board.
Signed-off-by: Andre Schwarz [EMAIL PROTECTED]
---
Grant,
I've fixed the dts issues from David (cell-index on gpt).
Please let me know if v3 still contains errors.
Thanks again for helping !
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
arch/powerpc/boot/dts/mvbc-p.dts | 254 ++
arch/powerpc/configs/52xx/mvbc_p_defconfig | 1158 ++
arch/powerpc/platforms/52xx/Kconfig |3 +-
arch/powerpc/platforms/52xx/mpc5200_simple.c |1 +
4 files changed, 1415 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mvbc-p.dts b/arch/powerpc/boot/dts/mvbc-p.dts
new file mode 100644
index 000..6167c0b
--- /dev/null
+++ b/arch/powerpc/boot/dts/mvbc-p.dts
@@ -0,0 +1,254 @@
+/*
+ * mvBlueCOUGAR-P device tree source
+ *
+ * Copyright (C) 2008 Matrix Vision GmbH
+ * Andre Schwarz [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = matrix-vision,mvbc-p;
+ compatible = matrix-vision,mvbc-p;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 0x4000;
+ i-cache-size = 0x4000;
+ timebase-frequency = 0;
+ bus-frequency = 0;
+ clock-frequency = 0;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc5200b-immr;
+ ranges = 0 0xf000 0xc000;
+ reg = 0xf000 0x0100;
+ bus-frequency = 0;
+ system-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc5200b-cdm,fsl,mpc5200-cdm;
+ reg = 0x200 0x38;
+ };
+
+ mpc5200_pic: [EMAIL PROTECTED] {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ compatible = fsl,mpc5200b-pic,fsl,mpc5200-pic;
+ reg = 0x500 0x80;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 0x600 0x10;
+ interrupts = 1 9 0;
+ interrupt-parent = mpc5200_pic;
+ fsl,has-wdt;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 0x610 0x10;
+ interrupts = 1 10 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 0x620 0x10;
+ interrupts = 1 11 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 0x630 0x10;
+ interrupts = 1 12 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 0x640 0x10;
+ interrupts = 1 13 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 0x650 0x10;
+ interrupts = 1 14 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
Re: [PATCH v2] Add MPC5200B base board mvBC-P
David Gibson schrieb:
On Mon, Jul 07, 2008 at 10:14:29AM +0200, Andre Schwarz wrote:
The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit
ethernet
controller (using e1000). It's just another MPC5200_simple board.
[snip]
+[EMAIL PROTECTED] { // General Purpose Timer
+compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+reg = 0x600 0x10;
+interrupts = 1 9 0;
+interrupt-parent = mpc5200_pic;
+fsl,has-wdt;
+};
+
+[EMAIL PROTECTED] { // General Purpose Timer
+compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+cell-index = 1;
What shared resource is this cell-index value used to index?
Also why does it not appear on the [EMAIL PROTECTED] but does on all the
others.
Sorry - it's a copy paste problem. At first I only used timer0, i.e.
this is the original entry.
After Grant wanting me to have a look at the lite5200b.dts I copied over
the rest of the dts nodes I also have on my board. On lite5200b.dts the
cell-index is defined.
If this is incorrect I'll remove it.
Is cell-index inappropriate for the timer node ?
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC5200B base board mvBC-P
David,
thanks - removed device_type from the DMA controller.
Which nodes actually require device_type and which don't ?
Is there some general rule ?
regards,
Andre
David Gibson schrieb:
On Fri, Jul 04, 2008 at 06:35:39PM +0200, Andre Schwarz wrote:
The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit
ethernet
controller (using e1000). It's just another MPC5200_simple board.
Signed-off-by: Andre Schwarz [EMAIL PROTECTED]
[snip]
--- /dev/null
+++ b/arch/powerpc/boot/dts/mvbc-p.dts
@@ -0,0 +1,206 @@
[snip]
+[EMAIL PROTECTED] {
+device_type = dma-controller;
No device_type here.
+compatible = fsl,mpc5200-bestcomm;
+reg = 0x1200 0x80;
+interrupts = 3 0 0 3 1 0 3 2 0 3 3 0
+3 4 0 3 5 0 3 6 0 3 7 0
+3 8 0 3 9 0 3 10 0 3 11 0
+3 12 0 3 13 0 3 14 0 3 15 0;
+interrupt-parent = mpc5200_pic;
+};
+
+[EMAIL PROTECTED] {
+compatible = fsl,mpc5200-xlb;
+reg = 0x1f00 0x100;
+};
+
+serial0: [EMAIL PROTECTED] {// PSC1
+device_type = serial;
+compatible = fsl,mpc5200-psc-uart;
+port-number = 0;
+reg = 0x2000 0x100;
+interrupts = 2 1 0;
+interrupt-parent = mpc5200_pic;
+};
+
+[EMAIL PROTECTED] {
+#address-cells = 1;
+#size-cells = 0;
+compatible = fsl,mpc5200-i2c,fsl-i2c;
+reg = 0x3d00 0x40;
+interrupts = 2 15 0;
+interrupt-parent = mpc5200_pic;
+fsl5200-clocking;
+};
+
+[EMAIL PROTECTED] {
+#address-cells = 1;
+#size-cells = 0;
+compatible = fsl,mpc5200-i2c,fsl-i2c;
+reg = 0x3d40 0x40;
+interrupts = 2 16 0;
+interrupt-parent = mpc5200_pic;
+fsl5200-clocking;
+};
+[EMAIL PROTECTED] {
+compatible = fsl,mpc5200-sram,sram;
+reg = 0x8000 0x4000;
+};
+};
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] Add MPC5200B base board mvBC-P
The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit ethernet
controller (using e1000). It's just another MPC5200_simple board.
Signed-off-by: Andre Schwarz [EMAIL PROTECTED]
---
Grant,
please find attached the re-submitted patch with mods as you requested.
I've also fixed the dts regarding to David's proposal.
Please let me know if anything is still incorrect.
Thanks again,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
arch/powerpc/boot/dts/mvbc-p.dts | 261 ++
arch/powerpc/configs/52xx/mvbc_p_defconfig | 1158 ++
arch/powerpc/platforms/52xx/Kconfig |3 +-
arch/powerpc/platforms/52xx/mpc5200_simple.c |1 +
4 files changed, 1422 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mvbc-p.dts b/arch/powerpc/boot/dts/mvbc-p.dts
new file mode 100644
index 000..2392dc2
--- /dev/null
+++ b/arch/powerpc/boot/dts/mvbc-p.dts
@@ -0,0 +1,261 @@
+/*
+ * mvBlueCOUGAR-P device tree source
+ *
+ * Copyright (C) 2008 Matrix Vision GmbH
+ * Andre Schwarz [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = matrix-vision,mvbc-p;
+ compatible = matrix-vision,mvbc-p;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 0x4000;
+ i-cache-size = 0x4000;
+ timebase-frequency = 0;
+ bus-frequency = 0;
+ clock-frequency = 0;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc5200b-immr;
+ ranges = 0 0xf000 0xc000;
+ reg = 0xf000 0x0100;
+ bus-frequency = 0;
+ system-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc5200b-cdm,fsl,mpc5200-cdm;
+ reg = 0x200 0x38;
+ };
+
+ mpc5200_pic: [EMAIL PROTECTED] {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ compatible = fsl,mpc5200b-pic,fsl,mpc5200-pic;
+ reg = 0x500 0x80;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ reg = 0x600 0x10;
+ interrupts = 1 9 0;
+ interrupt-parent = mpc5200_pic;
+ fsl,has-wdt;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ cell-index = 1;
+ reg = 0x610 0x10;
+ interrupts = 1 10 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ cell-index = 2;
+ reg = 0x620 0x10;
+ interrupts = 1 11 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ cell-index = 3;
+ reg = 0x630 0x10;
+ interrupts = 1 12 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
+ cell-index = 4;
+ reg = 0x640 0x10;
+ interrupts = 1 13 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt
MPC52xx generic DMA using bestcomm
Grant, do you know if someone's working on a more generic DMA solution using BestComm engine on 5200B ? Maybe somthing that accepts a sg-list with callback ops or completion ? Is it possible right now to accelerate simple memcpy ops ? regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
GPIO @ MPC5200
Sascha, Grant, I'm running on 2.6.26-rc6 with an MPC5200B based system. Looks like some (for me) crucial GPIO are touched during boot. Is this possible ? Of course I have compiled in GPIO-Lib and specified the GPIOs in the dts. But no access yet - I'd like to preserve the setup from u-boot... regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO @ MPC5200
Grant Likely schrieb: On Fri, Jul 04, 2008 at 11:57:14AM +0200, Andre Schwarz wrote: Sascha, Grant, I'm running on 2.6.26-rc6 with an MPC5200B based system. Looks like some (for me) crucial GPIO are touched during boot. Is this possible ? Of course I have compiled in GPIO-Lib and specified the GPIOs in the dts. But no access yet - I'd like to preserve the setup from u-boot... The GPIO driver only writes to the GPIO registers when a driver actually requests to use them. At probe time, the gpio drivers read the current values from the GPIO registers, so current config should be preserved. However, the gpiochip_dir hook explicitly sets the output value when it is called. It may be that when you are claiming the GPIO line it is getting set with a default (and wrong) value. Another possibility; have you verified that it is the GPIO regs getting clobbered? Or is port_config getting changed on you? Which GPIO pins? g. The pin in question is PSC2_4, i.e. a wake-up GPIO. It is configured as push-pull output and driven high. Since it has an external pull-down resistor I can't say if it is driven low or re-configured as an input ... I removed GPIO Lib and the problem is gone. I'm not yet using it anyway under linux - they're mainly for system configuration (setting up muxes etc.). I'll dig into it when I have some time. thanks, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add MPC5200B base board mvBC-P
The mvBlueCOUGAR-P is a MPC5200B based camera system with Intel Gigabit ethernet
controller (using e1000). It's just another MPC5200_simple board.
Signed-off-by: Andre Schwarz [EMAIL PROTECTED]
---
Grant,
I don't know if there are any merge windows ...
If the patch should be modified or re-submitted on a later time please let me
know.
thanks,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
arch/powerpc/boot/dts/mvbc-p.dts | 206 +
arch/powerpc/configs/mvbc-p_defconfig| 1158 ++
arch/powerpc/platforms/52xx/Kconfig |3 +-
arch/powerpc/platforms/52xx/mpc5200_simple.c |1 +
4 files changed, 1367 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mvbc-p.dts b/arch/powerpc/boot/dts/mvbc-p.dts
new file mode 100644
index 000..90a2808
--- /dev/null
+++ b/arch/powerpc/boot/dts/mvbc-p.dts
@@ -0,0 +1,206 @@
+/*
+ * mvBlueCOUGAR-P device tree source
+ *
+ * Copyright (C) 2008 Matrix Vision GmbH
+ * Andre Schwarz [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = matrix-vision,mvbc-p;
+ compatible = matrix-vision,mvbc-p;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 0x4000;
+ i-cache-size = 0x4000;
+ timebase-frequency = 0;
+ bus-frequency = 0;
+ clock-frequency = 0;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc5200-immr;
+ ranges = 0 0xf000 0xc000;
+ reg = 0xf000 0x0100;
+ bus-frequency = 0;
+ system-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc5200-cdm;
+ reg = 0x200 0x38;
+ };
+
+ mpc5200_pic: [EMAIL PROTECTED] {
+ // 5200 interrupts are encoded into two levels;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ compatible = fsl,mpc5200-pic;
+ reg = 0x500 0x80;
+ };
+
+ [EMAIL PROTECTED] { // General Purpose Timer
+ compatible = fsl,mpc5200-gpt;
+ reg = 0x600 0x10;
+ interrupts = 1 9 0;
+ interrupt-parent = mpc5200_pic;
+ fsl,has-wdt;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc5200-gpio;
+ reg = 0xb00 0x40;
+ interrupts = 1 7 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc5200-gpio-wkup;
+ reg = 0xc00 0x40;
+ interrupts = 1 8 0 0 3 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] {
+ device_type = dma-controller;
+ compatible = fsl,mpc5200-bestcomm;
+ reg = 0x1200 0x80;
+ interrupts = 3 0 0 3 1 0 3 2 0 3 3 0
+ 3 4 0 3 5 0 3 6 0 3 7 0
+ 3 8 0 3 9 0 3 10 0 3 11 0
+ 3 12 0 3 13 0 3 14 0 3 15 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc5200-xlb;
+ reg = 0x1f00 0x100;
+ };
+
+ serial0: [EMAIL PROTECTED] {// PSC1
+ device_type = serial;
+ compatible = fsl,mpc5200-psc-uart;
+ port-number = 0;
+ reg = 0x2000 0x100;
+ interrupts = 2 1 0;
+ interrupt-parent = mpc5200_pic;
+ };
+
+ [EMAIL PROTECTED
user memory access problem
Actually we're running 2.6.26-rc6 with MPC8343 and MPC5200B based boards.
Our kernel driver implements a read functions that initiates a DMA
operation into that user memory - nothing special.
For testing purposes this memory can be touched from the kernel using
memset.
1. User memory is translated to sg by get_user_pages during read syscall.
2. walk sg entries and map each page using kmap
3. memset the kmap'ed mem
4. SetPageDirty and unmap.
Running this code leads to memory corruption and SegFaults on the
Application side.
This code worked fine on 2.6.19.
Can anybody help me out here ?
um is a pointer to an internal struct holding the sg_list besides
other information...
for (i=0; ium-page_cnt; i++) {
data = i 0xff;
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,25)
kva = kmap(um-sl[i].page) + um-sl[i].offset;
#else
kva = kmap(sg_page(um-sl[i])) + um-sl[i].offset;
#endif
if (kva) {
/*leads to SegFault ... */
memset (kva, data, um-sl[i].length);
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,25)
SetPageDirty(um-sl[i].page);
kunmap(sg_page(um-sl[i].page));
#else
SetPageDirty(sg_page(um-sl[i]));
kunmap(sg_page(um-sl[i]));
#endif
}
}
regards,
Andre Schwarz
Matrix Vision
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
slow MMC over SPI
All, has anybody made some investigations about performance of a SD/MMC card on SPI ? Actually I'm using various cards (different speed classes) on an SPI bus of a MPC8343 cpu. Everything is working fine basically, i.e. card is detected properly and block device can be mounted and used. SPI clock is adjusted to the card's capabilities and is running quite fast (30MHz). But between consecutive reads/writes there's a fixed gap of 2us thus yielding a poor performance of approx. 300KBytes/sec. The spi bus is utilized only ~10%. Any ideas where this comes from ? Ist it a fixed delay regarding to some kind of spec or is it possibly a spi driver/mmc layer issue ? regards, Andre Schwarz MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
USB @ MPC834x
Scott, Li,
I'm sorry to bother you again ... but after bringing up all parts of my
MPC8343 based board the not working USB is the last pending problem.
Actually I'm running on 2.6.25 with a custom board.
Since USB is different for MPC8349/7/3 (depending on package) there
_could_ be a configuration problem.
Maybe you can help me out or give some hints at last.
Situation:
MPC8343A with ULPI-PHY (USB3300 from SMSC) connected the same way as on
the Freescale MPC8349EA_MDS_PB-TBGA Board, i.e. using ULPI mode of the
USB dual role module.
Do you know if this PHY has ever been running on any Freescale board ?
Do you know of _any_ MPC8343 based board running USB with an OTG PHY ?
Or has it always been a 8349 thus having both ports available ?
There are quite a few things that make me wonder :
Regarding to MPC8343EA manual I only have DR_D0..D7 pins available for
the DualRole module.
The port is labeled Port1 - it's the only one that is bonded inside
the small package.
On the Freescale schematics the pins DR_D0..D7 are labeld Port0.
arch/powerpc/platforms/83xx/usb.c contains mpc834x_usb_cfg which is
called during board init :
- sccr gets modified to match DR/MPH clock settings - I don't have the
MPH defined in my dts - it's only DR @ 0x23000 :
[EMAIL PROTECTED] {
device_type = usb;
compatible = fsl-usb2-dr;
reg = 0x23000 0x1000;
#address-cells = 1;
#size-cells = 0;
interrupt-parent = ipic;
interrupts = 38 0x8;
dr_mode = host;
phy_type = ulpi;
};
- In SICRH bit14 gets cleared by sicrh = in_be32(immap +
MPC83XX_SICRH_OFFS) ~MPC834X_SICRH_USB_UTMI.
Is bit14 not required to be set in DR configuration ?
- If ULPI is set then SICRL always uses port0:
} else if (prop !strcmp(prop, ulpi)) {
sicrl |= MPC834X_SICRL_USB0;
Is this also correct for MPC8343 ? Do we need MPC834X_SICRL_USB1 on 8343 ?
Any help is welcome.
regards,
Andre Schwarz
Matrix Vision
log messages during boot :
mpc83xx_spi.0: MPC83xx SPI Controller driver at 0xd1062000 (irq = 20)
ehci_hcd: block sizes: qh 128 qtd 96 itd 160 sitd 96
initializing FSL-SOC USB Controller
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
drivers/usb/core/inode.c: creating file 'devices'
drivers/usb/core/inode.c: creating file '001'
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: reset hcs_params 0x10011 dbg=0 ind cc=0 pcc=0
ordered ports=1
fsl-ehci fsl-ehci.0: reset hcc_params 0006 thresh 0 uframes 256/512/1024
park
fsl-ehci fsl-ehci.0: park 0
fsl-ehci fsl-ehci.0: reset command 080b02 park=3 ithresh=8 period=1024
Reset HALT
fsl-ehci fsl-ehci.0: ...powerdown ports...
fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
fsl-ehci fsl-ehci.0: reset command 080b02 park=3 ithresh=8 period=1024
Reset HALT
fsl-ehci fsl-ehci.0: init command 010009 (park)=0 ithresh=1 period=256 RUN
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: default language 0x0409
usb usb1: uevent
usb usb1: usb_probe_device
usb usb1: configuration #1 chosen from 1 choice
usb usb1: adding 1-0:1.0 (config #1, interface 0)
usb 1-0:1.0: uevent
hub 1-0:1.0: usb_probe_interface
hub 1-0:1.0: usb_probe_interface - got id
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
hub 1-0:1.0: standalone hub
hub 1-0:1.0: individual port power switching
hub 1-0:1.0: individual port over-current protection
hub 1-0:1.0: Single TT
hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns)
hub 1-0:1.0: power on to power good time: 20ms
hub 1-0:1.0: local power source is good
hub 1-0:1.0: enabling power on all ports
hub 1-0:1.0: state 7 ports 1 chg evt
drivers/usb/core/inode.c: creating file '001'
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Freescale On-Chip EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.25 ehci_hcd
usb usb1: SerialNumber: fsl-ehci.0
usbcore: registered new interface driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for
USB modems and ISDN adapters
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
EXT_IRQ0 @ MPC834x
All, actually I'm having trouble getting the IRQ0 work on a MPC8343 with 2.6.25-rc8. There's an external PCI device connected to it Regarding to the manual IRQ0 is somewhat special and has Vector 48 assigned. Therefore my dts entry for this device looks like : interrupt-map = 0x5800 0 0 1 ipic 0x30 0x8 ... ; Having a look on virq mapping gives : mvBL-M7 cat /sys/kernel/debug/powerpc/virq_mapping virq hwirqchip namehost name 16 0xe IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 17 0xf IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 18 0x9 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 20 0x00010 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 32 0x00020 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 33 0x00021 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 34 0x00022 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 38 0x00026 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] 48 0x00030 IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED] After loading the device driver (=mvbcdma) the irq shows up correctly. mvBL-M7 cat /proc/interrupts CPU0 16:603 IPIC Level i2c-mpc 17: 8 IPIC Level i2c-mpc 18:295 IPIC Level serial 20:341 IPIC Level mpc83xx_spi 32: 2 IPIC Level enet_tx 33: 3 IPIC Level enet_rx 34: 0 IPIC Level enet_error 38: 0 IPIC Level ehci_hcd:usb1 48: 0 IPIC Level mvbcdma0 BAD: 0 As soon as the device generates an interrupt I get : irq 48: nobody cared (try booting with the irqpoll option) handlers: [d18d66e8] (mvbcdma_irq+0x0/0x180 [mvbcdma]) Disabling IRQ #48 The handler _would_ have returned IRQ_RETVAL(1). Obviously the handler isn't called at all - but why ? Using nm on the kernel module gives : 06e8 t mvbcdma_irq -offset 0x6e8 inside module matches with output regarding handler. Any help is welcome ! regards, Andre Schwarz MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Question on MPC83xx interrupts
All, I'm currently running a MPC8343 based board. Looks like I'm having problems with IRQs of a PCI device. /proc/interrupts give : CPU0 16:554 IPIC Level i2c-mpc 17: 11 IPIC Level i2c-mpc 18:134 IPIC Level ath 19: 1557 IPIC Level serial 21:341 IPIC Level mpc83xx_spi 38: 0 IPIC Level ehci_hcd:usb1 BAD: 2 I wonder if the IRQ number should match the vector of the datasheet ... giving : 14 - I2C1 15 - I2C2 16 - SPI 38 - USB DR The ath is a PCI Ath5k WiFi module connected to IRQ1, i.e. mapped to vector 17. Are the IRQ numbers shifted/mapped/scrambled in any way ? Can anyone shed some light on this ? Cheers, Andre Schwarz Matrix Vision MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on MPC83xx interrupts
Scott Wood schrieb: On Tue, Apr 22, 2008 at 06:58:33PM +0200, Andre Schwarz wrote: I wonder if the IRQ number should match the vector of the datasheet ... giving : No. The numbers in /proc/interrupts are virtual IRQ numbers, which are a purely Linux-internal construct. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev Scott, thanks - any Idea how to figure out where the BAD comes from ? Is it simply an unhandled/unacked one ? regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on MPC83xx interrupts
Scott Wood schrieb: On Tue, Apr 22, 2008 at 07:36:48PM +0200, Andre Schwarz wrote: thanks - any Idea how to figure out where the BAD comes from ? Is it simply an unhandled/unacked one ? It generally happens when an interrupt is requested, and the core takes the exception, but then the interrupt source deasserts itself. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev So this is not bad at all if you have a device with self-clearing interrupts ... Thanks, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
USB @ MPC8343
Dear List,
on my MPC8343 based board there is a USB3300 ULPI-PHY connected to the
processor.
It's an OTG capable PHY but host mode should be enough right now.
Since USB is not used inside bootloader it's not configured at all...
As far as I can see the setup should be done inside the kernel completely.
My dts looks like this :
[EMAIL PROTECTED] {
device_type = usb;
compatible = fsl-usb2-dr;
reg = 0x23000 0x1000;
#address-cells = 1;
#size-cells = 0;
interrupt-parent = ipic;
interrupts = 38 0x8;
dr_mode = host;
phy_type = ulpi;
port1;
};
Since the MPC8343 has only one USB port I assume it is port1 since the
port1-pins are coming out of the package :-)
DR registers are located @ 0x23000
Kernel log :
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Freescale On-Chip EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.25-rc8-01233-g6249f9d-dirty ehci_hcd
usb usb1: SerialNumber: fsl-ehci.0
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
usbcore: registered new interface driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for
USB modems and ISDN adapters
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
Clocks and communication are looking fine (from an electrical point of
view) and bus power is applied.
But : no device (mouse, memory stick, ...) gets recognized.
No interrupts either.
An hints ?
regards,
Andre Schwarz
Matrix Vision
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Flash on LocalBus @ MPC8343
Scott,
there has been a compatible=soc in my of_bus_id[] ...
It was taken from mpc834x_mds some weeks ago.
I changed to :
static struct of_device_id __initdata of_bus_ids[] = {
{ .compatible = fsl,pq2pro-localbus, },
{},
};
now it works fine.
Thanks !
Andre
Scott Wood schrieb:
On Sat, Apr 12, 2008 at 10:58:50AM +0200, André Schwarz wrote:
thanks , but ... can't find of_bus_ids[] entry.
That means your platform likely isn't calling of_platform_bus_probe() at
all. Look at other platforms, such as mpc831x_rdb, for an example.
I'm obviously out of sync. My last git-pull from denx is 3 days old, now
- need to update on monday.
For Denx-specific support, please contact Denx.
This certainly isn't something that was added in the past 3 days.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Flash on LocalBus @ MPC8343
Hi all,
I've been trying hard to make the mtd-partitions available via device
tree on my MPC8343 local bus.
No success so far ...
Everything works fine on my MPC5200B based system - flash layout
definition is quite simple
To me it looks like there's a problem regarding the local bus in general.
Am I missing a compatible or anything else ? reg or ranges ?
The other boards use static map files or provide partition over command
line args so suitable dts available.
Flash is 8MB size in 16-Bit configuration and should reside on
0xFF80 at cs0.
Any hints ?
regards,
Andre Schwarz
Matrix Vision
dts syntax :
snip
[EMAIL PROTECTED] {
#address-cells = 2;
#size-cells = 1;
compatible = fsl,mpc8343-localbus, fsl,pq2pro-localbus;
ranges = 0x0 0x0 0xff80 0x0080;
[EMAIL PROTECTED],0 {
compatible = amd,s29gl64, cfi-flash;
reg = 0 0 80;
#address-cells = 1;
#size-cells = 1;
bank-width = 2;
device-width = 2;
[EMAIL PROTECTED] {
reg = 0x0 0x2000;
};
snip
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8343 - unable to handle paging request @ 0
Scott Wood schrieb: Andre Schwarz wrote: Scott Wood schrieb: Andre Schwarz wrote: - find_legacy_serial_port() stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED] It looks like you have some memory corruption between here... clocksource: timebase mult[3c1] shift[22] registered !! - check_legacy_serial_console() can't find stdout package /[EMAIL PROTECTED]/[EMAIL PROTECTED] ! !!! ...and here. -Scott Scott, are you talking about a possible hardware problem or misbehaving code ? Either. The same OF call is done in both places with the same argument, but is getting different results. Does it look like something gets overwritten during initrd extraction/movement ? Don't know. The system has 512MB RAM which means that we need 2 BAT regs to map the memory. I've found comments in Freescale u-boot header files that currently a max of 256MB is supported. I never understood why ? Could this problem be related to this ? Kim's probably be the best one to answer u-boot questions. -Scott Scott + Kim, as mentioned before I have re-built u-boot with the following modifications : - Reduce Memsize from 512 to 256MB - Skipped 2nd BAT setup dtb looks the same but memory size set to 256MB. System boots fine - this is weird ! I'm not really familiar with the powerpc tree of the kernel and far out of sync with the current development. Could you have a look at this ? Any ideas right now ? Thanks, Andre ## Booting kernel from Legacy Image at ff81 ... Image Name: 2.6.25 mvBL-M7 MPC8343 #12 Image Type: PowerPC Linux Kernel Image (uncompressed) Data Size:2494236 Bytes = 2.4 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK ## Flattened Device Tree blob at Booting using the fdt blob at 0x60 ## Loading init Ramdisk from Legacy Image at 0100 ... Image Name: mvBC-1G uInitrd #1.1.03 Image Type: PowerPC Linux RAMDisk Image (uncompressed) Data Size:2654208 Bytes = 2.5 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fcb7000, end 0ff3f000 ... OK - early_init_devtree(c060) search chosen, depth: 0, uname: search chosen, depth: 1, uname: chosen Looking for initrd properties... 3initrd_start=0xcfcb7000 initrd_end=0xcff3f000 Command line is: root=/dev/ram ro rootfstype=squashfs dt_root_size_cells = 1 dt_root_addr_cells = 1 memory scan node memory, reg size 8, data: 0 1000 2 1, - 0 , 1000 reserving: fcb7000 - 288001 Phys. mem: 1000 - move_device_tree - move_device_tree Scanning CPUs ... boot cpu: logical 0 physical 0 - early_init_devtree() Using mvBlueLYNX-M7 machine description Linux version 2.6.25-rc8-01197-g1de15bb-dirty ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #12 PREEMPT Wed Apr 9 14:40:48 CEST 2008 - unflatten_device_tree() size is 192c, allocating... unflattening cfffe6d0... fixed up name for - fixed up name for chosen - chosen fixed up name for [EMAIL PROTECTED] - wdt fixed up name for [EMAIL PROTECTED] - ethernet-phy fixed up name for [EMAIL PROTECTED] - ethernet-phy fixed up name for [EMAIL PROTECTED] - ethernet fixed up name for [EMAIL PROTECTED] - ethernet fixed up name for [EMAIL PROTECTED] - serial fixed up name for [EMAIL PROTECTED] - serial fixed up name for [EMAIL PROTECTED] - pic fixed up name for [EMAIL PROTECTED] - ppcboot_env fixed up name for [EMAIL PROTECTED] - ppcboot_env_red fixed up name for [EMAIL PROTECTED] - u-boot_autoscript fixed up name for [EMAIL PROTECTED] - u-boot_autoscript_red fixed up name for [EMAIL PROTECTED] - dtb fixed up name for [EMAIL PROTECTED] - dtb_red fixed up name for [EMAIL PROTECTED] - kernel fixed up name for [EMAIL PROTECTED] - rfs fixed up name for [EMAIL PROTECTED] - u-boot fixed up name for [EMAIL PROTECTED] - fpga - unflatten_device_tree() Found initrd at 0xcfcb7000:0xcff3f000 - find_legacy_serial_port() stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED] legacy_serial_console = 0 default console speed = 115740 - find_legacy_serial_port() console [udbg0] enabled setup_arch: bootmem mvblm7_setup_arch() Adding PCI host bridge /[EMAIL PROTECTED] Found MPC83xx PCI host bridge at 0xe0008500. Firmware bus number: 0-0 -Hose at 0xc0281000, cfg_addr=0xfdffd300,cfg_data=0xfdffd304 PCI host bridge /[EMAIL PROTECTED] (primary) ranges: MEM 0x9000..0x9fff - 0x9000 MEM 0x8000..0x8fff - 0x8000 Prefetch IO 0xe200..0xe20f - 0x arch: exit Zone PFN ranges: DMA 0 -65536 Normal 65536 -65536 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -65536 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/ram ro
Re: MPC8343 - unable to handle paging request @ 0
Scott Wood schrieb: On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote: after building a debug kernel and attaching the bdi2000 it looks like the crash occurs during console_init() ... Does your device tree have a /chosen node after u-boot is done with it? find_legacy_serial_ports() can crash otherwise (we really should fix that). Since we're using a dtb I omit the console=... argument for the kernel. Is this correct ? It's OK if you have /chosen/linux,stdout-path. If console=/dev/ttyS0,115200N8 argument is given the serial console stops working after console_init On other PowerPC system I could see something like this during boot : - find_legacy_serial_port() stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED] legacy_serial_console = 1 default console speed = 115340 - find_legacy_serial_port() Should I see this message also ? Only if you enable debug messages in legacy_serial.c. Have I misconfigured anything ? One thing that sticks out from the above is that you ask for ttyS0, but the stdout you list from the other system corresponds to ttyS1. Is this just a difference between the two systems? -Scott Scott, I've added kallsyms and the #debug in legacy_serial. Obviously there's missing something - see error can't find stdout package /[EMAIL PROTECTED]/[EMAIL PROTECTED] ! below. Can you help here ? Thanks, Andre ## Booting kernel from Legacy Image at ff81 ... Image Name: 2.6.25 mvBL-M7 MPC8343 #12 Image Type: PowerPC Linux Kernel Image (uncompressed) Data Size:2494236 Bytes = 2.4 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK ## Flattened Device Tree blob at Booting using the fdt blob at 0x60 ## Loading init Ramdisk from Legacy Image at 0100 ... Image Name: mvBC-1G uInitrd #1.1.03 Image Type: PowerPC Linux RAMDisk Image (uncompressed) Data Size:2654208 Bytes = 2.5 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 1fcb7000, end 1ff3f000 ... OK - early_init_devtree(c060) search chosen, depth: 0, uname: search chosen, depth: 1, uname: chosen Looking for initrd properties... 3initrd_start=0xdfcb7000 initrd_end=0xdff3f000 Command line is: root=/dev/ram ro rootfstype=squashfs dt_root_size_cells = 1 dt_root_addr_cells = 1 memory scan node memory, reg size 8, data: 0 2000 2 1, - 0 , 2000 reserving: 1fcb7000 - 288001 Phys. mem: 2000 - move_device_tree - move_device_tree Scanning CPUs ... boot cpu: logical 0 physical 0 - early_init_devtree() Using mvBlueLYNX-M7 machine description Linux version 2.6.25-rc8-01197-g1de15bb-dirty ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #12 PREEMPT Wed Apr 9 14:40:48 CEST 2008 - unflatten_device_tree() size is 192c, allocating... unflattening dfffe6d0... fixed up name for - fixed up name for chosen - chosen fixed up name for [EMAIL PROTECTED] - wdt fixed up name for [EMAIL PROTECTED] - ethernet-phy fixed up name for [EMAIL PROTECTED] - ethernet-phy fixed up name for [EMAIL PROTECTED] - ethernet fixed up name for [EMAIL PROTECTED] - ethernet fixed up name for [EMAIL PROTECTED] - serial fixed up name for [EMAIL PROTECTED] - serial fixed up name for [EMAIL PROTECTED] - pic fixed up name for [EMAIL PROTECTED] - ppcboot_env fixed up name for [EMAIL PROTECTED] - ppcboot_env_red fixed up name for [EMAIL PROTECTED] - u-boot_autoscript fixed up name for [EMAIL PROTECTED] - u-boot_autoscript_red fixed up name for [EMAIL PROTECTED] - dtb fixed up name for [EMAIL PROTECTED] - dtb_red fixed up name for [EMAIL PROTECTED] - kernel fixed up name for [EMAIL PROTECTED] - rfs fixed up name for [EMAIL PROTECTED] - u-boot fixed up name for [EMAIL PROTECTED] - fpga - unflatten_device_tree() Found initrd at 0xdfcb7000:0xdff3f000 - find_legacy_serial_port() stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED] legacy_serial_console = 0 default console speed = 115740 - find_legacy_serial_port() console [udbg0] enabled setup_arch: bootmem mvblm7_setup_arch() arch: exit Zone PFN ranges: DMA 0 - 131072 Normal 131072 - 131072 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 131072 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: root=/dev/ram ro rootfstype=squashfs PID hash table entries: 2048 (order: 11, 8192 bytes) clocksource: timebase mult[3c1] shift[22] registered !! - check_legacy_serial_console() can't find stdout package /[EMAIL PROTECTED]/[EMAIL PROTECTED] ! !!! Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 514048k/524288k available (2328k kernel code, 9676k reserved, 88k data, 126k bss, 140k init) SLUB
Re: MPC8343 - unable to handle paging request @ 0
Scott Wood schrieb: Andre Schwarz wrote: - find_legacy_serial_port() stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED] It looks like you have some memory corruption between here... clocksource: timebase mult[3c1] shift[22] registered !! - check_legacy_serial_console() can't find stdout package /[EMAIL PROTECTED]/[EMAIL PROTECTED] ! !!! ...and here. -Scott Scott, are you talking about a possible hardware problem or misbehaving code ? Does it look like something gets overwritten during initrd extraction/movement ? The system has 512MB RAM which means that we need 2 BAT regs to map the memory. I've found comments in Freescale u-boot header files that currently a max of 256MB is supported. I never understood why ? Could this problem be related to this ? Do I need to supply reserved memory regions ? I thought u-boot is doing so for initrd and the kernel don't need it ... I'll rebuild u-boot with 256MB memory size and do an extra run with memory test - just to make sure. Any hints where to look else ? regards, Andre MATRIX VISION GmbH, Talstra�e 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Gesch�ftsf�hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8343 - unable to handle paging request @ 0
Scott Wood schrieb: On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote: Kernel starts and crashes with unable to handle kernel paging request @ . After turning debug on in some files I can see that the initrd memory gets reserved and the dtb is parsed correctly. PCI memory/io spaces are set up fine. At first I thought this is a problem with the device tree since the call trace always points to of_-functions and strcmp. Could you provide this call trace? -Scott Scott, thanks for your reply. please find below the output after the bootm command in u-boot. My System.map : ... c00126b8 T strcpy c00126d4 T strncpy c0012714 T strcat c0012740 T strcmp c0012764 T strlen c001277c T memcmp ... c0140bc4 T of_find_property c0140c74 T of_get_property c0140ca8 T of_device_is_compatible c0140d48 T of_match_node c0140e68 T of_find_matching_node c0140f20 T of_n_size_cells c0140f9c T of_n_addr_cells Log: # Booting kernel from Legacy Image at ff81 ... Image Name: 2.6.25 mvBL-M7 MPC8343 #1 Image Type: PowerPC Linux Kernel Image (uncompressed) Data Size:2084636 Bytes = 2 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK ## Flattened Device Tree blob at Booting using the fdt blob at 0x60 ## Loading init Ramdisk from Legacy Image at 0100 ... Image Name: mvBC-1G uInitrd #1.1.03 Image Type: PowerPC Linux RAMDisk Image (uncompressed) Data Size:2654208 Bytes = 2.5 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 1fcb7000, end 1ff3f000 ... OK - early_init_devtree(c060) search chosen, depth: 0, uname: search chosen, depth: 1, uname: chosen Looking for initrd properties... 3initrd_start=0xdfcb7000 initrd_end=0xdff3f000 Command line is: root=/dev/ram ro rootfstype=squashfs dt_root_size_cells = 1 dt_root_addr_cells = 1 memory scan node memory, reg size 8, data: 0 2000 2 1, - 0 , 2000 reserving: 1fcb7000 - 288001 Phys. mem: 2000 - move_device_tree - move_device_tree Scanning CPUs ... boot cpu: logical 0 physical 0 - early_init_devtree() Using mvBlueLYNX-M7 machine description Linux version 2.6.25-rc8-01197-g1de15bb-dirty ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 PREEMPT Tue Apr 8 10:40:51 CEST 2008 - unflatten_device_tree() size is 1840, allocating... unflattening dfffe7bc... fixed up name for - fixed up name for chosen - chosen fixed up name for aliases - aliases fixed up name for cpus - cpus fixed up name for PowerPC,[EMAIL PROTECTED] - PowerPC,8343 fixed up name for memory - memory fixed up name for [EMAIL PROTECTED] - soc8343 fixed up name for [EMAIL PROTECTED] - wdt fixed up name for [EMAIL PROTECTED] - i2c fixed up name for [EMAIL PROTECTED] - rtc fixed up name for [EMAIL PROTECTED] - i2c fixed up name for [EMAIL PROTECTED] - spi fixed up name for [EMAIL PROTECTED] - usb fixed up name for [EMAIL PROTECTED] - mdio fixed up name for [EMAIL PROTECTED] - ethernet-phy fixed up name for [EMAIL PROTECTED] - ethernet-phy fixed up name for [EMAIL PROTECTED] - ethernet fixed up name for [EMAIL PROTECTED] - ethernet fixed up name for [EMAIL PROTECTED] - serial fixed up name for [EMAIL PROTECTED] - serial fixed up name for [EMAIL PROTECTED] - pic fixed up name for [EMAIL PROTECTED] - localbus fixed up name for [EMAIL PROTECTED],0 - flash - unflatten_device_tree() Found initrd at 0xdfcb7000:0xdff3f000 console [udbg0] enabled setup_arch: bootmem mvblm7_setup_arch() Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0012748 Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT mvBlueLYNX-M7 Modules linked in: NIP: c0012748 LR: c0140c10 CTR: REGS: c01f9e40 TRAP: 0300 Not tainted (2.6.25-rc8-01197-g1de15bb-dirty) MSR: 1032 ME,IR,DR CR: 22008048 XER: 2000 DAR: , DSISR: 2000 TASK = c01e4510[0] 'swapper' THREAD: c01f8000 GPR00: c0140c84 c01f9ef0 c01e4510 c0197a7f c01f9edc GPR08: c01f15e4 0003 c0600b84 004d 22002048 ffdf 1fffd000 GPR16: ffdf 7fdf 1fff8974 1ff426f8 0004 00288000 GPR24: 0002 5f0f c01993e4 c01f9f28 c0197a80 c01f8000 d9e4 Call Trace: [c01f9ef0] [c001c190] (unreliable) [c01f9f10] [c0140c84] [c01f9f20] [c0140ccc] [c01f9f40] [c014145c] [c01f9f60] [c0014014] [c01f9fa0] [c01d1a40] [c01f9fb0] [c01ce64c] [c01f9fc0] [c01c55ac] [c01f9ff0] [3438] Instruction dump: 3884 8c050001 2c00 4082fff8 38a5 8c040001 2c00 9c050001 4082fff4 4e800020 38a3 3884 8c650001 2c83 8c040001 7c601851 ---[ end trace 8640abe69a316dee ]--- Kernel panic - not syncing: Attempted to kill the idle task! Rebooting in 180 seconds.. Please let me know if you need more information. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht
[Fwd: Re: MPC8343 - unable to handle paging request @ 0]
sorry - forgot Kim + List Original-Nachricht Betreff:Re: MPC8343 - unable to handle paging request @ 0 Datum: Tue, 08 Apr 2008 13:29:20 +0200 Von:Andre Schwarz [EMAIL PROTECTED] An: Scott Wood [EMAIL PROTECTED] Referenzen: [EMAIL PROTECTED] [EMAIL PROTECTED] Scott Wood schrieb: On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote: Kernel starts and crashes with unable to handle kernel paging request @ . After turning debug on in some files I can see that the initrd memory gets reserved and the dtb is parsed correctly. PCI memory/io spaces are set up fine. At first I thought this is a problem with the device tree since the call trace always points to of_-functions and strcmp. Could you provide this call trace? -Scott Scott, after removing mpc834x_usb_cfg() from my mvblm7_setup_arch() the crash is delayed ... regards, Andre System-map : c0012098 T strcpy c00120b4 T strncpy c00120f4 T strcat c0012120 T strcmp c0012144 T strlen ... c00ecd08 T of_find_property c00ecda4 T of_get_property c00ecdd8 T of_n_size_cells console [udbg0] enabled setup_arch: bootmem mvblm7_setup_arch() arch: exit Zone PFN ranges: DMA 0 - 131072 Normal 131072 - 131072 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 131072 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: root=/dev/ram ro rootfstype=squashfs PID hash table entries: 2048 (order: 11, 8192 bytes) clocksource: timebase mult[3c1] shift[22] registered Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0012128 Oops: Kernel access of bad area, sig: 11 [#1] mvBlueLYNX-M7 Modules linked in: NIP: c0012128 LR: c00ecd44 CTR: 0007 REGS: c0193ec0 TRAP: 0300 Not tainted (2.6.25-rc8-01197-g1de15bb-dirty) MSR: 9032 EE,ME,IR,DR CR: 48002048 XER: DAR: , DSISR: 2000 TASK = c0182510[0] 'swapper' THREAD: c0192000 GPR00: c00ecdb4 c0193f70 c0182510 c01401c7 c017a808 c00db350 GPR08: c018 000a2c20 c017d3f4 4842 dfd7 1fffd000 GPR16: dfd7 dfd7 1fff8974 1ff426f8 0004 00288000 GPR24: c0198fa0 c019 c019 c01401c8 dfa8 Call Trace: [c0193f70] [] (unreliable) [c0193f90] [c00ecdb4] [c0193fa0] [c016df50] [c0193fb0] [c017705c] [c0193fc0] [c01646b4] [c0193ff0] [3438] Instruction dump: 3884 8c050001 2c00 4082fff8 38a5 8c040001 2c00 9c050001 4082fff4 4e800020 38a3 3884 8c650001 2c83 8c040001 7c601851 ---[ end trace 8640abe69a316dee ]--- Kernel panic - not syncing: Attempted to kill the idle task! Rebooting in 180 seconds.. MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8343 - unable to handle paging request @ 0
Scott Wood schrieb:
On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote:
Kernel starts and crashes with unable to handle kernel paging request @
.
After turning debug on in some files I can see that the initrd memory
gets reserved and the dtb is parsed correctly.
PCI memory/io spaces are set up fine.
At first I thought this is a problem with the device tree since the call
trace always points to of_-functions and strcmp.
Could you provide this call trace?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Scott,
after building a debug kernel and attaching the bdi2000 it looks like
the crash occurs during console_init() ...
Since we're using a dtb I omit the console=... argument for the
kernel. Is this correct ?
If console=/dev/ttyS0,115200N8 argument is given the serial console
stops working after console_init
On other PowerPC system I could see something like this during boot :
- find_legacy_serial_port()
stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
legacy_serial_console = 1
default console speed = 115340
- find_legacy_serial_port()
Should I see this message also ?
Have I misconfigured anything ?
u-boot prints the following dtb :
...
aliases {
name = aliases;
ethernet0 = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
ethernet1 = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
serial0 = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
serial1 = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
pci0 = /[EMAIL PROTECTED];
};
cpus {
name = cpus;
#address-cells = 0x0001;
#size-cells = 0x;
PowerPC,[EMAIL PROTECTED] {
name = PowerPC,8343;
device_type = cpu;
reg = 0x;
d-cache-line-size = 0x0020;
i-cache-line-size = 0x0020;
d-cache-size = 0x8000;
i-cache-size = 0x8000;
timebase-frequency = 0x03f940aa;
bus-frequency = 0x0fe502a8;
clock-frequency = 0x17d783fc;
};
};
memory {
name = memory;
device_type = memory;
reg = 0x 0x2000;
};
[EMAIL PROTECTED] {
name = soc8343;
#address-cells = 0x0001;
#size-cells = 0x0001;
device_type = soc;
compatible = soc;
ranges = [00 00 00 00 e0 00 00 00 00 10 00 00];
reg = 0xe000 0x0200;
bus-frequency = 0x0fe502a8;
[EMAIL PROTECTED] {
device_type = watchdog;
compatible = mpc83xx_wdt;
reg = 0x0200 0x0100;
};
[EMAIL PROTECTED] {
name = i2c;
#address-cells = 0x0001;
#size-cells = 0x;
cell-index = 0x;
compatible = fsl-i2c;
reg = 0x3000 0x0100;
interrupts = 0x000e 0x0008;
interrupt-parent = 0x0001;
dfsrr;
};
[EMAIL PROTECTED] {
name = i2c;
#address-cells = 0x0001;
#size-cells = 0x;
cell-index = 0x0001;
compatible = fsl-i2c;
reg = 0x3100 0x0100;
interrupts = 0x000f 0x0008;
interrupt-parent = 0x0001;
dfsrr;
};
[EMAIL PROTECTED] {
name = spi;
cell-index = 0x;
compatible = fsl,spi;
reg = 0x7000 0x1000;
interrupts = 0x0010 0x0008;
interrupt-parent = 0x0001;
mode = cpu;
};
[EMAIL PROTECTED] {
name = usb;
compatible = fsl-usb2-mph;
reg = 0x00022000 0x1000;
#address-cells = 0x0001;
#size-cells = 0x;
interrupt-parent = 0x0001;
interrupts = 0x0027 0x0008;
phy_type = ulpi;
port0;
};
[EMAIL PROTECTED] {
name = mdio;
#address-cells =
Oops MPC8343 @ 2.6.25-rc7
All,
I'm having trouble booting a MPC8343 into a recent 2.6.25-rc7 kernel.
Kernel config has been reduced to a minimum : no PCI, no netwoking, i2c,
spi ...
dts has been reduced to the CPU, soc and ipic nodes.
U-Boot fills out dtb correctly - as far as I can see.
Kernel crashes on various of_ functions regarding to call trace.
There's also strange messages :
WARNING: Estimating decrementer frequency (not found)
WARNING: Estimating processor frequency (not found)
They're coming from generic_calibrate_decr() in kernel/time.c.
Looks like there something basically wrong with my dtb
location/processing, since the timebase-frequency is present and valid :
cpus {
#address-cells = 0x0001;
#size-cells = 0x;
PowerPC,[EMAIL PROTECTED] {
device_type = cpu;
reg = 0x;
d-cache-line-size = 0x0020;
i-cache-line-size = 0x0020;
d-cache-size = 0x8000;
i-cache-size = 0x8000;
timebase-frequency = 0x03f940aa;
bus-frequency = 0x0fe502a8;
clock-frequency = 0x17d783fc;
};
};
Any hints ?
regards,
Andre Schwarz
Matrix Vision
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: simple MPC5200B system
Grant, I've pulled the latest git and built a mpc5200_simple system with a minimal dts. There's not a single char put on the console Grant Likely schrieb: On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz [EMAIL PROTECTED] wrote: All, I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+ ... maybe someone could give me some hints. Up to now the systems have been running on 2.6.19 without any problems. This is what I've done so far : - get a recent system with 2.6.19 running and keep the toolchain (gcc 4.0) including RFS uImage. - latest bootloader (u-boot 1.3.2) is running fine with dtb support. - Kernel and RFS images are available via bootp/tftp - device tree blob seems ok, i.e. u-boot can display the blob and fill in all clocks correctly. - Kernel gets called with Kernel, RFS and dtb on suitable adresses (0x10, 0x60, 0x5F). - nothing more happens. It looks like the console isn't working properly - maybe worse ... Can you either halt the processor or reset the board and access memory after this point? You should see if you can access __log_buf (Look in System.map for the address and subtract 0xc000 to get the physical address). __log_buf should give you clues about how far booting progresses. (c033d4b4 b __log_buf) yields all zeroes - nothing logged at all. Examining the CPU state with the bdi shows : Target CPU: MPC8280/8220/5200 (Zeppo) Target state : debug mode Debug entry cause : COP halt Current PC: 0xc000552c Current CR: 0x4842 Current MSR : 0x9032 Current LR: 0xc00166c0 The program counter shows the adress of irq_set_virq_count which has a BUG() macro. Looks like this one evaluates to true. What do you think ? The kernel has been build using the MPC5200 simple setup. I've added our board identifier mv,mvbluecougar to the list of supported boards in the mpc52xx_simple.c file. This identifier is used in the dtb as well of course. This should be enough along with a valid device tree blob, isn't it ? Did I miss anything already ? Yes, this should be enough (on a side note; it should probably be matrix-vision,bluecougar unless of''mv' is your company's stock ticker symbol). As far as I did understand by reading the docs it should be possible running a general MPC52xx kernel with a custom dtb ? Is this correct ? That is correct. The dts file has already been reduced to a minimum, i.e. only the cpu, pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm, pci, ata or advanced features like mtd partitions. All I want to get working is the serial console on /dev/ttyPSC0. Cheers, g. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: simple MPC5200B system
Grant, sorry for having troubled you. Looks like the build system has been in an invalid state... After doing a git-pull and make distclean + make mpc5200_defconfig the system is finally up and running. Using mpc5200-simple-platform machine description Linux version 2.6.25-rc6-00978-g275c005-dirty ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #9 Tue Mar 18 11:25:07 CET 2008 Found initrd at 0xc397a000:0xc3c0 arch/powerpc/platforms/52xx/mpc52xx_common.c: Error mapping XLB in mpc52xx_setup_cpu(). Expect some abnormal behavior Zone PFN ranges: DMA 0 -16384 Normal 16384 -16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: root=/dev/ram ro rootfstype=squashfs ip=192.168.65.57::192.168.65.15:255.255.255.0 console=ttyPSC0,115200N8 e1000.TxDescriptors=1500 e1000.SmartPowerDownEnable=1 MPC52xx PIC is up and running! PID hash table entries: 256 (order: 8, 1024 bytes) clocksource: timebase mult[79364d9] shift[22] registered console [ttyPSC0] enabled regards, Andre Andre Schwarz schrieb: Grant, I've pulled the latest git and built a mpc5200_simple system with a minimal dts. There's not a single char put on the console Grant Likely schrieb: On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz [EMAIL PROTECTED] wrote: All, I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+ ... maybe someone could give me some hints. Up to now the systems have been running on 2.6.19 without any problems. This is what I've done so far : - get a recent system with 2.6.19 running and keep the toolchain (gcc 4.0) including RFS uImage. - latest bootloader (u-boot 1.3.2) is running fine with dtb support. - Kernel and RFS images are available via bootp/tftp - device tree blob seems ok, i.e. u-boot can display the blob and fill in all clocks correctly. - Kernel gets called with Kernel, RFS and dtb on suitable adresses (0x10, 0x60, 0x5F). - nothing more happens. It looks like the console isn't working properly - maybe worse ... Can you either halt the processor or reset the board and access memory after this point? You should see if you can access __log_buf (Look in System.map for the address and subtract 0xc000 to get the physical address). __log_buf should give you clues about how far booting progresses. (c033d4b4 b __log_buf) yields all zeroes - nothing logged at all. Examining the CPU state with the bdi shows : Target CPU: MPC8280/8220/5200 (Zeppo) Target state : debug mode Debug entry cause : COP halt Current PC: 0xc000552c Current CR: 0x4842 Current MSR : 0x9032 Current LR: 0xc00166c0 The program counter shows the adress of irq_set_virq_count which has a BUG() macro. Looks like this one evaluates to true. What do you think ? The kernel has been build using the MPC5200 simple setup. I've added our board identifier mv,mvbluecougar to the list of supported boards in the mpc52xx_simple.c file. This identifier is used in the dtb as well of course. This should be enough along with a valid device tree blob, isn't it ? Did I miss anything already ? Yes, this should be enough (on a side note; it should probably be matrix-vision,bluecougar unless of''mv' is your company's stock ticker symbol). As far as I did understand by reading the docs it should be possible running a general MPC52xx kernel with a custom dtb ? Is this correct ? That is correct. The dts file has already been reduced to a minimum, i.e. only the cpu, pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm, pci, ata or advanced features like mtd partitions. All I want to get working is the serial console on /dev/ttyPSC0. Cheers, g. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: simple MPC5200B system
Grant Likely schrieb: On Tue, Mar 18, 2008 at 4:34 AM, Andre Schwarz [EMAIL PROTECTED] wrote: Grant, sorry for having troubled you. Looks like the build system has been in an invalid state... After doing a git-pull and make distclean + make mpc5200_defconfig the system is finally up and running. Heh; I hate it when that happens. :-) Congratulations. g. Grant, this leads to the next questions ... :-) I've read some discussions about the interrupt-map attribute of the pci node. I tried to follow Ben and David in their explanations - obviously I didn't really get it. Looks like there are a lot of people outside who need some enlightenment ... including me, of course. Maybe you can clarify this ? Taken from motionpro.dts ... interrupt-map = c000 0 0 1 mpc5200_pic 0 0 3 // 1st slot c000 0 0 2 mpc5200_pic 1 1 3 c000 0 0 3 mpc5200_pic 1 2 3 c000 0 0 4 mpc5200_pic 1 3 3 c800 0 0 1 mpc5200_pic 1 1 3 // 2nd slot c800 0 0 2 mpc5200_pic 1 2 3 c800 0 0 3 mpc5200_pic 1 3 3 c800 0 0 4 mpc5200_pic 0 0 3; First parameter seems to be the slot number, i.e. IDSEL line of the PCI device. How is this value coded ? Are these the bits 15..11 of the configuration address ? 2nd + 3rd paramter : no clue ! can you explain ? 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only INT_A. Do we need 4 entries in any case ? 5th : ok - parent pic 6th ... 8th : IRQ representation of the parent pic, which gives : 6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins 7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have number 1..3 inside MAIN level. 8th : should be 3 = level low which is default for PCI. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: simple MPC5200B system
Grant Likely schrieb: On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz [EMAIL PROTECTED] wrote: I've read some discussions about the interrupt-map attribute of the pci node. I tried to follow Ben and David in their explanations - obviously I didn't really get it. Looks like there are a lot of people outside who need some enlightenment ... including me, of course. Maybe you can clarify this ? Taken from motionpro.dts ... First, you also need to look at interrupt-map-mask to interpret these values; from motionpro.dts: interrupt-map-mask = f800 0 0 7; which is applied to the unit interrupt specifier to figure out how to map onto the interrupt controller. The /size/ of this field is obtained by adding #address-cells with #interrupt-cells. (3+1=4). 'f8' refers to the upper 5 bits of the interrupt identifier which is a number from 0-31 which relates to the IDSEL line as you guessed. The '7' covers the lower 3 bits of the interrupt specifier which can be 1, 2, 3 or 4. The 120 bits in the middle are irrelevant, so interrupt-map-mask leaves them as zeros. ok. interrupt-map = c000 0 0 1 mpc5200_pic 0 0 3 // 1st slot c000 0 0 2 mpc5200_pic 1 1 3 c000 0 0 3 mpc5200_pic 1 2 3 c000 0 0 4 mpc5200_pic 1 3 3 c800 0 0 1 mpc5200_pic 1 1 3 // 2nd slot c800 0 0 2 mpc5200_pic 1 2 3 c800 0 0 3 mpc5200_pic 1 3 3 c800 0 0 4 mpc5200_pic 0 0 3; First parameter seems to be the slot number, i.e. IDSEL line of the PCI device. How is this value coded ? Are these the bits 15..11 of the configuration address ? I don't remember how this is encoded. On the lite5200, idsel is wired to d0 and d1 for slots 1 and 2 respectively, yet these values suggest slots 24 and 25. I'll need to look at this again later. pci info from u-boot shows both devices (e1000 NIC + FPGA) 00 0a 4d56 1000 ff00 03- bus 0 , slot 0a, irq 3 00 0b 8086 1078 0200 02 - bus 0 , slot 0b, irq 2 IDSEL mapping of MPC5200 is 0b0_1011 for slot 0xb and 0b0_1010 for slot 0xa. Using those 5 bits = 3 for the first cell gives 5800 and 5000 2nd + 3rd paramter : no clue ! can you explain ? first 3 cells are the unit address and is #address-cells large. Only the first cell contains real data. ok. 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only INT_A. Do we need 4 entries in any case ? you only need entries for irq lines that are wired up. If your board does not wire up _B, _C and _D, then don't have an entry for them. However, if they are wired up then you should describe them. ok. I only have INT_A. 5th : ok - parent pic Correct. 6th ... 8th : IRQ representation of the parent pic, which gives : 6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins 7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have number 1..3 inside MAIN level. 8th : should be 3 = level low which is default for PCI. Correct. There is also some good information here: http://playground.sun.com/1275/practice/imap/imap0_9d.pdf Cheers, g. using the following interrupt-map give me two working PCI devices with working interrupts ... :-) interrupt-map = 5800 0 0 1 mpc5200_pic 1 2 3 // e1000 5000 0 0 1 mpc5200_pic 1 3 3;// FPGA Thanks for your explanations ! regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
