unsubscribe
Sadly, after >20 years
Re: [PATCH] Enable CONFIG_DEVTMPFS_MOUNT to ensure /dev can be mounted correctly
On 2013-04-17 05:46, Luo Zhenhua-B19537 wrote: -Original Message- From: Michael Ellerman [mailto:mich...@ellerman.id.au] Sent: Monday, April 15, 2013 1:02 PM On Thu, Apr 11, 2013 at 09:56:30PM +0800, Zhenhua Luo wrote: When using recent udev, the /dev node mount requires CONFIG_DEVTMPFS_MOUNT is enabled in Kernel. Really? I know it makes life easier when you don't have an initramfs, but is it actually required now? [Luo Zhenhua-B19537] I didn't use initramfs when the issue is found, I think the option is required to be enabled. Yes, it is required to get udev to work properly (versions of udev newer than ~173) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove PReP
On 2013-03-27 06:42, Paul Bolle wrote: On Wed, 2013-03-27 at 13:05 +0100, Geert Uytterhoeven wrote: This section is CHRP-specific. The cs4232 driver also worked on the CHRP LongTrail. But I don't remember if the parameter values above also applied to LongTrail. I do remember it didn't work without specifing the right parameters, so you probably want to keep this section. My reasoning was quite simply that this file was 14 years old so that probably nobody is using that stuff anymore. Are people actually using CHRP (whatever that is)? Anyhow, cs4232 is mentioned in some other files Common Hardware Reference Platform - see http://en.wikipedia.org/wiki/Common_Hardware_Reference_Platform too: $ git grep -l -n cs4232 Documentation/ Documentation/powerpc/sound.txt Documentation/sound/alsa/ALSA-Configuration.txt Documentation/sound/alsa/alsa-parameters.txt Documentation/sound/oss/Introduction Documentation/sound/oss/Tropez+ Could these few lines be dumped in one of these (except powerpc/sound.txt, of course)? Seeing this stuff go marks the end of an era (the PreP and CHRP platforms were some of the very first devices to run Linux back in 1995...) I just sent my last one to the recycler a few months back :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Using gpio in MPC8309
On 2012-07-12 18:08, Gal Afel wrote: Hello, I just got a TWR-MPC8309 from Freescale running Embedded Linux OS. The kernel version is Linux 2.6.11+pq3 patches and the kernel preconfig file is linux_2.6.11_mpc8548_cds_def.config. That's a really OLD kernel, plus it doesn't seem to match your hardware. MPC8309 is a very different beast from the MPC8548. I'm new to processors running Linux and I'm having a hard time trying to understand how can I program the GPIO and use them. Is there a tutorial or any documentation you could provide me to get started on accessing the processor pins please? I'm using CodeWarrior Development Studio for Power Architecture version 10.0.2 and I haven't found a library that includes the functions to access the pins functionality. Is there any documentation you could suggest me to do that please? Try looking at the Linux kernel source file 'Documentation/gpio.txt' -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Network problem with 3.3
n.b. sorry if you receive this twice - ThunderBird seems very crashy lately!
I'm trying to update my MPC8379 board from 3.0 to 3.3. I have
this setup in my device tree:
mdio@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 0x24520 0x20;
phy0: ethernet-phy@0 {
interrupt-parent = ipic;
interrupts = 17 0x8;
reg = 0x01;
device_type = ethernet-phy;
};
phy1: ethernet-phy@1 {
interrupt-parent = ipic;
interrupts = 18 0x8;
reg = 0x00;
device_type = ethernet-phy;
};
};
enet0: ethernet@24000 {
cell-index = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 0x24000 0x1000;
local-mac-address = [ 00 08 e5 11 32 33 ];
interrupts = 32 0x8 33 0x8 34 0x8;
interrupt-parent = ipic;
phy-handle = phy0;
linux,network-index = 0;
};
enet1: ethernet@25000 {
cell-index = 1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 0x25000 0x1000;
local-mac-address = [ 00 08 e5 11 32 34 ];
interrupts = 35 0x8 36 0x8 37 0x8;
interrupt-parent = ipic;
phy-handle = phy1;
linux,network-index = 1;
};
On 3.0, this works just fine. When I boot the same setup on 3.3,
I get this error:
fsl-pq_mdio: probe of ff024520.mdio failed with error -16
Is there something I need to change in my DTS file to make this work?
Something else I might be missing?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Network problem with 3.3
I'm trying to port my MPC8379 board from 3.0 to 3.3. In 3.0, I have
this setup in my device tree:
mdio@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 0x24520 0x20;
phy0: ethernet-phy@0 {
interrupt-parent = ipic;
interrupts = 17 0x8;
reg = 0x01;
device_type = ethernet-phy;
};
phy1: ethernet-phy@1 {
interrupt-parent = ipic;
interrupts = 18 0x8;
reg = 0x00;
device_type = ethernet-phy;
};
};
enet0: ethernet@24000 {
cell-index = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 0x24000 0x1000;
local-mac-address = [ 00 08 e5 11 32 33 ];
interrupts = 32 0x8 33 0x8 34 0x8;
interrupt-parent = ipic;
phy-handle = phy0;
linux,network-index = 0;
};
enet1: ethernet@25000 {
cell-index = 1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 0x25000 0x1000;
local-mac-address = [ 00 08 e5 11 32 34 ];
interrupts = 35 0x8 36 0x8 37 0x8;
interrupt-parent = ipic;
phy-handle = phy1;
linux,network-index = 1;
};
On 3.0, this works just fine. When I boot the same setup on 3.3,
I get this error:
fsl-pq_mdio: probe of ff024520.mdio failed with error -16
Is there something I need to change in my DTS file to make this work?
Something else I might be missing?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Network problem with 3.3
On 2012-04-11 10:57, Joakim Tjernlund wrote:
On 2012-04-11 10:14, Gary Thomas wrote:
n.b. sorry if you receive this twice - ThunderBird seems very crashy lately!
I'm trying to update my MPC8379 board from 3.0 to 3.3. I have
this setup in my device tree:
mdio@24520 {
#address-cells =1;
#size-cells =0;
compatible = fsl,gianfar-mdio;
reg =0x24520 0x20;
phy0: ethernet-phy@0 {
interrupt-parent =ipic;
interrupts =17 0x8;
reg =0x01;
device_type = ethernet-phy;
};
phy1: ethernet-phy@1 {
interrupt-parent =ipic;
interrupts =18 0x8;
reg =0x00;
device_type = ethernet-phy;
};
};
enet0: ethernet@24000 {
cell-index =0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg =0x24000 0x1000;
local-mac-address = [ 00 08 e5 11 32 33 ];
interrupts =32 0x8 33 0x8 34 0x8;
interrupt-parent =ipic;
phy-handle =phy0;
linux,network-index =0;
};
enet1: ethernet@25000 {
cell-index =1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg =0x25000 0x1000;
local-mac-address = [ 00 08 e5 11 32 34 ];
interrupts =35 0x8 36 0x8 37 0x8;
interrupt-parent =ipic;
phy-handle =phy1;
linux,network-index =1;
};
On 3.0, this works just fine. When I boot the same setup on 3.3,
I get this error:
fsl-pq_mdio: probe of ff024520.mdio failed with error -16
Is there something I need to change in my DTS file to make this work?
Something else I might be missing?
I think I found it - I need to add a TBI node to my PHY setup.
It's working now.
Do you have a TBI PHY? There is a bug in 3.3 where every non-TBI PHY would
fail, see
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=464b57da56910c8737ede75ad820b9a7afc46b3e
for a fix.
Thanks. After applying this patch, networking is working fine on
my board, with no TBI node in the PHY.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Virtual addresses in arch/powerpc/boot/dts/tqm8548*.dts ?
On 2011-08-30 15:43, Paul Walmsley wrote: Hi, Looking at some of the PPC DTS files in arch/powerpc/boot/dts, there are some files that are mostly identical, except for some strange differences. For example, tqm8548.dts and tqm8548-bigflash.dts differ mostly in that the former file claims that the SoC registers start at 0xe000[1], but the latter file claims that the SoC registers start at 0xa000[2]. Commit 02b8a3d1eb2ae6353cfbce627ded22e299cf1989 (powerpc/85xx: support for the TQM8548 module using the big Flash) claims that: Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash memory and therefore a modified memory map is required and setup by the board loader. This patch adds an appropriate DTS file. So are these addresses virtual? My (perhaps incorrect) understanding of the device tree files was that they were intended to describe the physical memory map, rather than the virtual memory map. Or does this PowerPC variant have the ability to dynamically change its own physical address decoding? Or is something else going on? These addresses correspond to the internal registers which can be moved. The default address is set by hardware at reset time (check out the documentation on the hardware reset word). Obviously one board is strapped for the IMMR at one address, another board at a different address. I almost always configure my boards to use 0xF000 for the IMMR. thanks for any clarification, - Paul 1. arch/powerpc/boot/dts/tqm8548.dts line 53, as of Linux v3.1-rc3: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548.dts;h=619776f72c904c611e9507d44db4bee1200e6688;hb=HEAD#l53 2. arch/powerpc/boot/dts/tqm8548-bigflash.dts line 53, as of Linux v3.1-rc3: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548-bigflash.dts;h=9452c3c05114e523033eebb278d7f78811890a87;hb=HEAD#l53 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Kernel boot up
contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: HELP:PowerPc-Linux kernel
On 2011-08-01 05:31, naresh.kamb...@wipro.com wrote: Did you try passing 'console=ttyCPM0' to the bootargs? I have tried ttyCPM0 no use. Do I need to modify something on boot loader or is there any boot loader can support CPM ? What boot loader does your board use? Scott, Is cpm_console_init() must be initialized to fix this issue? Also, 2.6.21 is truly ancient. Why not try a more recent kernel, especially if you are just getting srarted? I think this is the time, for me to use latest kernel to work on. BR Naresh Kamboju -Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Saturday, July 30, 2011 5:59 PM To: Naresh Kamboju (WT01 - GMT-Telecom Equipment) Cc: linuxppc-dev@lists.ozlabs.org; scottw...@freescale.com; vijay.t.ni...@gmail.com; c...@fsmlabs.com Subject: Re: HELP:PowerPc-Linux kernel On 2011-07-30 06:21, naresh.kamb...@wipro.com wrote: Hi All, I have started working on powerpc board bring up. I have prepared dtb file and booted linux kernel with my debug statement. Problem: I could not see anything on the serial console. By using the emulator I can read __log_buf and found below info. How can I initialize the serial console? Here ttyCPM0 at MMIO map 0xc504aa00 mem 0x0 (irq = 40) is a CPM UART is detected by kernel and where we generally pass boot args as ttyS0. May I the relation between ttyCPM0 and ttyS0. How can I see kernel boot console on the serial port? It would be helpful if you share any workarounds. Did you try passing 'console=ttyCPM0' to the bootargs? Also, 2.6.21 is truly ancient. Why not try a more recent kernel, especially if you are just getting srarted? Below print out is from emulator by reading __log_buf and parsed as readable log. 6Using MPC82xx ADS machine description .3Initializing container subsys cpu. 5Linux version 2.6.21.7-hrt1-cfs-v22-grsec-WR2.0bl_cgl (vanga@linux) (gcc version 4.1.2 (Wind River Linux Sourcery G++ 4.1-91)) #18 Sat Jul 30 14:39:06 IST 2011 .7Entering add_active_range(0, 0, 16384) 0 entries of 256 used .6No memory reg property [1] in devicetree .7Top of RAM: 0x400, Total RAM: 0x400 .7Memory hole size: 0MB .4Zone PFN ranges: .4DMA 0 - 16384 .4Normal 16384 - 16384 . 4early_node_map[1] active PFN ranges .4 0:0 - 16384 .7On node 0 totalpages: 16384 .7DMA zone: 128 pages used for memmap .7DMA zone: 0 pages reserved .7DMA zone: 16256 pages, LIFO batch:3 .7Normal zone: 0 pages used for memmap.4Built 1 zonelists. Total pages: 16256. 5Kernel command line: mem=64M console=ttyS0,9600n8 root=/dev/nfs rw nfsroot=172.16.50.152:/home/export,nolock,rsize=1024,wsize=1024. 5---after parse_early_param--- . 5---after parse_args--- . 5enteredsort_main_extable 5exit sort_main_extable 5---after sort_main_extable()--- . 5---after trap_init()--- . 5---after rcu_init()--- .6No pci node on device tree. 5---after init_IRQ()--- .4PID hash table entries: 256 (order: 8, 1024bytes). 5---after pidhash_init--- . 5---after init_timers--- . 5---after hrtimers_init--- . 5---after softirq_init--- . 5---after timekeeping_init--- .7time_init: decrementer frequency = 16.675000 MHz .7time_init: processor fre quency = 166.75 MHz. 5---after time_init--- . 5---after profile_init--- . 5---after early_boot_irqs_on--- . 5---after local_irq_enable--- .6---entered in cpm_uart_console_init -- . 5---after console_init--- . 5---after pan ic check--- . 5---after lockdep_info--- . 5---after locking_selftest--- .4Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) .4Inode-cache hash table entries: 4096 (order: 2, 16384 bytes). 5---after vfs_caches_init_early---. 5---cpuset_init_early--- .6Memory: 61612k/65536k available (2848k kernel code, 3860k reserved, 84k data, 276k bss, 152k init). 5---after kmem_cache_init--- . 5---after locking_selftest--- . 5---after radix_tree_init--- . 5---after memleak_init--- . 5---after setup_per_cpu_pageset--- . 5---after numa_policy_init--- . 5---after late_time_init-- .7Calibrating delay loop... 33.28 BogoMIPS (lpj=66560). 5---after calibrate_delay--- . 5---after pidmap_init-- - . 5---after pgtable_cache_init--- . 5---after prio_tree_init--- . 5---after anon_vma_init--- . 5---after fork_init--- . 5---after proc_caches_init--- . 5---after buffer_init--- . 5---after unnamed_dev_init--- . 5---aft er key_init--- . 5---after security_init--- .4Mount-cache hash table entries: 512. 5---after vfs_caches_init--- . 5---after signals_init--- . 5---after page_writeback_init--- .3Initializing container subsys cpuacct .3Initializi ng container subsys debug. 5---after container_init--- . 5---after cpuset_init--- . 5---after taskstats_init_early-- . 5---after delayacct_init--- . 5---after check_bugs
Re: HELP:PowerPc-Linux kernel
information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
FSL USB in 2.6.37
I'm trying to get my platform support working in mainline 2.6.37. I have a MPC8379 which is working well in 2.6.32. When I just move my platform to the new kernel, everything works except for USB host mode. Nothing special about my platform - it's pretty much like the FSL eval boards (as far as this part is concerned). I can see it start up, claim to power up the internal hub, but I never see the state change interrupt from the hub. Are there any known gotchas here? Any ideas? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FSL USB in 2.6.37
On 02/15/2011 11:18 AM, Anatolij Gustschin wrote: On Tue, 15 Feb 2011 10:47:17 -0700 Gary Thomasg...@mlbassoc.com wrote: I'm trying to get my platform support working in mainline 2.6.37. I have a MPC8379 which is working well in 2.6.32. When I just move my platform to the new kernel, everything works except for USB host mode. Nothing special about my platform - it's pretty much like the FSL eval boards (as far as this part is concerned). I can see it start up, claim to power up the internal hub, but I never see the state change interrupt from the hub. Are there any known gotchas here? Any ideas? Does this patch [1] help? [1] http://patchwork.ozlabs.org/patch/78260/ Indeed, it fixes my problem :-) Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MMC on MPC8379
On 01/31/2011 01:12 PM, Gary Thomas wrote: I'm running 2.6.32 on MPC8379, trying to use the SDHCI interface. It seems to work, reads are fine, but when I write to the device (I've tried both eMMC soldered-on and pluggable MMC/SD cards), I get intermittent failures. Specifically, some blocks will be written while others fail. I haven't yet found a pattern. Is there anything special about this interface? I notice that it's not really used by any FSL platforms although the driver claims support. On the surface, it looks like it should work and I'm perplexed by the failures. Does anyone have any ideas or experience with this device? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
MMC on MPC8379
I'm running 2.6.32 on MPC8379, trying to use the SDHCI interface. It seems to work, reads are fine, but when I write to the device (I've tried both eMMC soldered-on and pluggable MMC/SD cards), I get intermittent failures. Specifically, some blocks will be written while others fail. I haven't yet found a pattern. Is there anything special about this interface? I notice that it's not really used by any FSL platforms although the driver claims support. Any ideas? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI woes with 2.6.37
On 01/08/2011 06:07 AM, Gary Thomas wrote: On 01/08/2011 12:33 AM, Benjamin Herrenschmidt wrote: On Fri, 2011-01-07 at 16:06 -0700, Gary Thomas wrote: I just tried porting my target (MPC8347) from 2.6.28 (remember that one?) to 2.6.37. Recently I tried this with 2.6.32 without a lot of success, so I thought I'd try the latest :-) The changes are very simple, pretty much just the addition of my 8347 based platform DTS. Sadly, it fails even worse than it did on 2.6.32. For some reason, although everything seems to report that the PCI bus is alive, MEM access fails completely. If I try to access various PCI devices via their memory space (I only have memory peripherals so I can't test IO space access), I get what I assume are BUS timeouts - all 0x My PCI bus is defined in DTS like this: ranges =0x0200 0x0 0xC000 0xC000 0x0 0x2000 What are the #address-cells and #size-cells properties of the parent of the PCI controller node ? PCI has 3 cells, so that accounts for the first 3 numbers of each of these. That leaves only 3 numbers, so either you have #address-cells = 1 and #size-cells = 2 or the other way around. The first sounds the most plausible and would mean that you are mapping c000 CPU space to c000 PCI space and the window is 512M long. Now of course, one needs to double check that the HW is configured that way (I suppose fsl_pci.c does the configuration based on the ranges property but I don't know for sure). So far nothing strikes me as totally odd. 0x0100 0x0 0x 0xB800 0x0 0x0010; This looks reasonable too with the same assumption as above. PCI: Probing PCI hardware PCI: Scanning PHB /p...@ff008500 PCI: PHB IO resource = -000FF FFf [100] PCI: PHB MEM resource 0 = c000-dFF FFfff [200] Did you edit those by hand ? :-) They look correct tho as far as I can tell. Sorry, I did a little editing of the dump below (to make it more readable, no content changes) and find replace went wild on me :-( It should have read: PCI: PHB MEM resource 0 = c000-dfff [200] PCI: PHB MEM offset = PCI: PHB IO offset = And that too. probe mode: 0 PCI::00:0b.0 Resource 0 1000-1007 [40101] fixup... PCI::00:0b.0 1000-1007 PCI::00:0b.0 Resource 1 1008-100b [40101] fixup... PCI::00:0b.0 1008-100b PCI::00:0b.0 Resource 2 1010-1017 [40101] fixup... PCI::00:0b.0 1010-1017 PCI::00:0b.0 Resource 3 1018-101b [40101] fixup... PCI::00:0b.0 1018-101b PCI::00:0b.0 Resource 4 1020-102f [40101] fixup... PCI::00:0b.0 1020-102f PCI::00:0b.0 Resource 5 0010-001001ff [40200] fixup... PCI::00:0b.0 0010-001001ff PCI::00:0b.0 Resource 6 -0007FF FF [4e200] is unassigned PCI::00:0c.0 Resource 0 0400-07FF FFff [40200] fixup... PCI::00:0c.0 0400-07FF FFff PCI: Fixup bus devices 0 (PHB) PCI: Try to map irq for :00:0b.0... Got one, spec 2 cells (0x0016 0x0008...) on /soc8...@ff00/p...@700 Mapped to linux irq 22 PCI: Try to map irq for :00:0c.0... Got one, spec 2 cells (0x0013 0x0008...) on /soc8...@ff00/p...@700 Mapped to linux irq 19 PCI: Allocating bus resources for :00... PCI: PHB (bus 0) bridge rsrc 0: -000FF FFf [0x100], parent c03b5740 (PCI IO) PCI: PHB (bus 0) bridge rsrc 1: c000-dFF FFfff [0x200], parent c03b5724 (PCI mem) PCI: Allocating :00:0b.0: Resource 0: 1000..1007 [40101] PCI: Allocating :00:0b.0: Resource 1: 1008..100b [40101] PCI: Allocating :00:0b.0: Resource 2: 1010..1017 [40101] PCI: Allocating :00:0b.0: Resource 3: 1018..101b [40101] PCI: Allocating :00:0b.0: Resource 4: 1020..102f [40101] PCI: Allocating :00:0b.0: Resource 5: 0010..001001ff [40200] PCI: Cannot allocate resource region 5 of device :00:0b.0, will remap PCI: Allocating :00:0c.0: Resource 0: 0400..07FF FFff [40200] That's huge, is this your Coral framebuffer ? It's clearly using a different address scheme which won't fit, so the kernel decides to remap it, so far so good. Indeed, the frame buffer takes 4MB PCI: Cannot allocate resource region 0 of device :00:0c.0, will remap Reserving legacy ranges for domain Candidate legacy IO: [io 0x-0x0fff] hose mem offset: hose mem res: [mem 0xc000-0xdFF FFfff] Local memory hole: [mem 0xc000-0xc01FF FFf] Now I can't grep the above
Re: PCI woes with 2.6.37
On 01/08/2011 12:33 AM, Benjamin Herrenschmidt wrote: On Fri, 2011-01-07 at 16:06 -0700, Gary Thomas wrote: I just tried porting my target (MPC8347) from 2.6.28 (remember that one?) to 2.6.37. Recently I tried this with 2.6.32 without a lot of success, so I thought I'd try the latest :-) The changes are very simple, pretty much just the addition of my 8347 based platform DTS. Sadly, it fails even worse than it did on 2.6.32. For some reason, although everything seems to report that the PCI bus is alive, MEM access fails completely. If I try to access various PCI devices via their memory space (I only have memory peripherals so I can't test IO space access), I get what I assume are BUS timeouts - all 0x My PCI bus is defined in DTS like this: ranges =0x0200 0x0 0xC000 0xC000 0x0 0x2000 What are the #address-cells and #size-cells properties of the parent of the PCI controller node ? PCI has 3 cells, so that accounts for the first 3 numbers of each of these. That leaves only 3 numbers, so either you have #address-cells = 1 and #size-cells = 2 or the other way around. The first sounds the most plausible and would mean that you are mapping c000 CPU space to c000 PCI space and the window is 512M long. Now of course, one needs to double check that the HW is configured that way (I suppose fsl_pci.c does the configuration based on the ranges property but I don't know for sure). So far nothing strikes me as totally odd. 0x0100 0x0 0x 0xB800 0x0 0x0010; This looks reasonable too with the same assumption as above. PCI: Probing PCI hardware PCI: Scanning PHB /p...@ff008500 PCI: PHB IO resource= -000FF FFf [100] PCI: PHB MEM resource 0 = c000-dFF FFfff [200] Did you edit those by hand ? :-) They look correct tho as far as I can tell. Sorry, I did a little editing of the dump below (to make it more readable, no content changes) and find replace went wild on me :-( It should have read: PCI: PHB MEM resource 0 = c000-dfff [200] PCI: PHB MEM offset = PCI: PHB IO offset = And that too. probe mode: 0 PCI::00:0b.0 Resource 0 1000-1007 [40101] fixup... PCI::00:0b.01000-1007 PCI::00:0b.0 Resource 1 1008-100b [40101] fixup... PCI::00:0b.01008-100b PCI::00:0b.0 Resource 2 1010-1017 [40101] fixup... PCI::00:0b.01010-1017 PCI::00:0b.0 Resource 3 1018-101b [40101] fixup... PCI::00:0b.01018-101b PCI::00:0b.0 Resource 4 1020-102f [40101] fixup... PCI::00:0b.01020-102f PCI::00:0b.0 Resource 5 0010-001001ff [40200] fixup... PCI::00:0b.00010-001001ff PCI::00:0b.0 Resource 6 -0007FF FF [4e200] is unassigned PCI::00:0c.0 Resource 0 0400-07FF FFff [40200] fixup... PCI::00:0c.00400-07FF FFff PCI: Fixup bus devices 0 (PHB) PCI: Try to map irq for :00:0b.0... Got one, spec 2 cells (0x0016 0x0008...) on /soc8...@ff00/p...@700 Mapped to linux irq 22 PCI: Try to map irq for :00:0c.0... Got one, spec 2 cells (0x0013 0x0008...) on /soc8...@ff00/p...@700 Mapped to linux irq 19 PCI: Allocating bus resources for :00... PCI: PHB (bus 0) bridge rsrc 0: -000FF FFf [0x100], parent c03b5740 (PCI IO) PCI: PHB (bus 0) bridge rsrc 1: c000-dFF FFfff [0x200], parent c03b5724 (PCI mem) PCI: Allocating :00:0b.0: Resource 0: 1000..1007 [40101] PCI: Allocating :00:0b.0: Resource 1: 1008..100b [40101] PCI: Allocating :00:0b.0: Resource 2: 1010..1017 [40101] PCI: Allocating :00:0b.0: Resource 3: 1018..101b [40101] PCI: Allocating :00:0b.0: Resource 4: 1020..102f [40101] PCI: Allocating :00:0b.0: Resource 5: 0010..001001ff [40200] PCI: Cannot allocate resource region 5 of device :00:0b.0, will remap PCI: Allocating :00:0c.0: Resource 0: 0400..07FF FFff [40200] That's huge, is this your Coral framebuffer ? It's clearly using a different address scheme which won't fit, so the kernel decides to remap it, so far so good. Indeed, the frame buffer takes 4MB PCI: Cannot allocate resource region 0 of device :00:0c.0, will remap Reserving legacy ranges for domain Candidate legacy IO: [io 0x-0x0fff] hose mem offset: hose mem res
PCI woes with 2.6.37
for domain Candidate legacy IO: [io 0x-0x0fff] hose mem offset: hose mem res: [mem 0xc000-0xdFF FFfff] Local memory hole: [mem 0xc000-0xc01FF FFf] PCI: Assigning unassigned resources... pci :00:0c.0: BAR 0: assigned [mem 0xc400-0xc7FF FFff] pci :00:0c.0: BAR 0: set to [mem 0xc400-0xc7FF FFff] (PCI address [0xc400-0xc7FF FFff]) pci :00:0b.0: BAR 6: assigned [mem 0xc020-0xc027FF FF pref] pci :00:0b.0: BAR 5: assigned [mem 0xc028-0xc02801ff] pci :00:0b.0: BAR 5: set to [mem 0xc028-0xc02801ff] (PCI address [0xc028-0xc02801ff]) ... Coral-P FB [1024x768x24] at 0xc400..0xc7FF FFff [0xd110] D110: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF || D1100010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF || D1100020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF || D1100030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF || D1100040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF || D1100050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF || D1100060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF || D1100070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF || ... scsi0 : sata_sil scsi1 : sata_sil ata1: SATA max UDMA/100 mmio m...@0xc028 tf 0xc0280080 irq 22 ata2: SATA max UDMA/100 mmio m...@0xc028 tf 0xc02800c0 irq 22 ata1: failed to resume link (SControl ) ata1: SATA link down (SStatus SControl ) ata2: failed to resume link (SControl ) ata2: SATA link down (SStatus SControl ) Things of note: * The 'local memory hole' is a space I have to steal from the PCI address space so that the Coral-P gets mapped to something other than PCI memory address 0x0 (relative). This device is dirt stupid (previously discussed) and refuses to work at 0x0 * The dump after the Coral-P FB line is what it sees in it's memory space. It _should_ look something like this: C4140600: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 || C4140610: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 || C4140620: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 || C4140630: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 || C4140640: FF FF FF 00 FF FF FF 00 FF FD FF 00 FF FD FF 00 || C4140650: FF FD FF 00 FF FD FF 00 FF FD FF 00 FF FD FF 00 || Notice how byte 3 of every longword is 0x00? * The SATA device driver is failing along similar lines. Any ideas what I'm doing wrong? or what I can look at? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Change in PCI behaviour
On 11/23/2010 07:44 AM, Gary Thomas wrote: On 11/22/2010 01:26 PM, Benjamin Herrenschmidt wrote: On Mon, 2010-11-22 at 03:01 -0700, Gary Thomas wrote: I have a bit more information on this. I'm pretty sure that the failures are only happening in my SCSI (SATA actually) code. My board (8347ea) has a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28. In 2.6.32, it will run for a while (possibly quite a while), then timeout trying to do a large block write - typically 256 blocks. Once this timeout happens, the SIL controller is stuck and accesses to it will eventually cause the whole system to hang (as above). Was there any major change in how PCI or DMA was handled between 2.6.28 and 2.6.32? Given the ephemeral nature of these failures (multiple runs all eventually fail, but never the same twice), my only hope of fixing it will be to have some ideas what might have changed. Maybe the changes you did to the PCI outbound windows are now breaking DMA ? Make sure the outbound and inbound don't overlap for example and that all RAM is reachable for inbound. Here's what I did to work around this - in my DTS, I set up my PCI as ranges = 0x0200 0x0 0xC400 0xC400 0x0 0x1C00 0x0100 0x0 0x 0xB800 0x0 0x0010; Before, I had it as ranges = 0x0200 0x0 0xC000 0xC000 0x0 0x2000 0x0100 0x0 0x 0xB800 0x0 0x0010; I wasn't sure how to reserve the memory (based on your earlier suggestion), so I just narrowed the window. Note that I did not change the PCI hardware registers (maybe the FSL code does?), so the outbound window should still be the whole 512MB. If this isn't viable, perhaps you could explain a bit more how to reserve such a chunk of memory so that the PCI mappings remain the same. Any ideas on this? I'm a bit lost as to how to reserve the memory like you suggested and what I've tried so far has met little success. Thanks again -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PHY/FEC Network adapter failed to initialize on MPC52xx Board
On 11/27/2010 06:31 AM, Peter wrote: Hi all I got completely stuck with a network adapter problem on my ppc board (MPC52xx style). The ntwork adapter does not seem to intialize correctly when booted without 'help from uboot' The adapter works properly when I first use it with uboot. E.g. using tftp to load the kernel or just issuing a dummy sntp command. It does not get intialized if I boot linux without using any network relevant command in ubboot The difference manifests on the boot message: (working) PHY working ... mpc52xx MII bus: probed TCP cubic registered NET: Registered protocol family 17 IP-Config: Complete: device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2, host=192.168.1.245, domain=, nis-domain=(none), bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath= Looking up port of RPC 13/2 on 192.168.1.244 Looking up port of RPC 15/1 on 192.168.1.244 VFS: Mounted root (nfs filesystem) on device 0:11. Freeing unused kernel memory: 124k init PHY: f0003000:00 - Link is Up - 100/Full # ping 192.168.1.2 returns proper results. PHY Not working: ... mpc52xx MII bus: probed TCP cubic registered NET: Registered protocol family 17 IP-Config: Complete: device=eth0, addr=192.168.1.245, mask=255.254.0.0, gw=192.168.1.2, host=192.168.1.245, domain=, nis-domain=(none), bootserver=192.168.1.244, rootserver=192.168.1.244, rootpath= VFS: Mounted root (squashfs filesystem) readonly on device 31:3. Freeing unused kernel memory: 124k init # ping 192.168.1.2 hangs The second snipped does not have Looking up.. messages because it boots from flash. Main difference is PHY: f0003000:00 - Link is Up - 100/Full which does not appear at the failing case. Linux Version is 2.6.35.7 patched with xenomai 2.5 U-Boot 2010.06 (Aug 05 2010 - 19:54:45) Linux configuration see below: ( i left most entries out that are not set) I also experimented with different settings but finally only CONFIG_FEC_MPC52xx=y and CONFIG_FEC_MPC52xx_MDIO=y seem to be of any relevance. If both are set, the adapter works when initialized by uboot. Any help or tips will be very much appreciated, There are a couple of possibilities: * Many PHY devices will have an external RESET or enable pin which is driven by GPIO. The board support package in U-Boot for your board would then enable the PHY device as part of network initialization. The Linux kernel typically does not fiddle with such things. * The actual PHY device may need some setup (adjustment of internal PHY registers) before it will come on-line, e.g. the device may not be strapped to auto-negotiate on the wire to find a link. U-Boot might be turning this on, or even forcing the link up (I've seen such devices that needed this level of hand-holding). Again, the Linux network driver typically will not be doing these sort of operations. To figure out what's going on and what else you might need, you should look at both the U-Boot code for your board and the board documentation (schematics, etc). Then you should be able to see what U-Boot does that the Linux kernel is not. In the end, you may need to add some code in your target platform support in Linux to add the additional stuff to make the PHY work. Linux .config ... # # Platform support # # CONFIG_PPC_CHRP is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y # CONFIG_PPC_EFIKA is not set CONFIG_PPC_LITE5200=y # CONFIG_PPC_MEDIA5200 is not set CONFIG_PPC_MPC5200_BUGFIX=y # CONFIG_PPC_MPC5200_GPIO is not set CONFIG_PPC_MPC5200_LPBFIFO=y CONFIG_PPC_BESTCOMM=y CONFIG_PPC_BESTCOMM_FEC=y CONFIG_PPC_BESTCOMM_GEN_BD=y # CONFIG_SIMPLE_GPIO is not set .. # Bus options # CONFIG_ZONE_DMA=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_PCI_CHOICE=y ... # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_MTD=y CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CMDLINE_PARTS=y # # MII PHY device drivers # CONFIG_LXT_PHY=y## Does not seem to have any influence CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_ETHOC=y ## Does not seem to have any influence CONFIG_FEC_MPC52xx=y ## Must be Y in roder to get adapter working with uboot's init CONFIG_FEC_MPC52xx_MDIO=y ## Must be Y in roder to get adapter working with uboot's init ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Change in PCI behaviour
On 11/22/2010 01:26 PM, Benjamin Herrenschmidt wrote: On Mon, 2010-11-22 at 03:01 -0700, Gary Thomas wrote: I have a bit more information on this. I'm pretty sure that the failures are only happening in my SCSI (SATA actually) code. My board (8347ea) has a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28. In 2.6.32, it will run for a while (possibly quite a while), then timeout trying to do a large block write - typically 256 blocks. Once this timeout happens, the SIL controller is stuck and accesses to it will eventually cause the whole system to hang (as above). Was there any major change in how PCI or DMA was handled between 2.6.28 and 2.6.32? Given the ephemeral nature of these failures (multiple runs all eventually fail, but never the same twice), my only hope of fixing it will be to have some ideas what might have changed. Maybe the changes you did to the PCI outbound windows are now breaking DMA ? Make sure the outbound and inbound don't overlap for example and that all RAM is reachable for inbound. Here's what I did to work around this - in my DTS, I set up my PCI as ranges = 0x0200 0x0 0xC400 0xC400 0x0 0x1C00 0x0100 0x0 0x 0xB800 0x0 0x0010; Before, I had it as ranges = 0x0200 0x0 0xC000 0xC000 0x0 0x2000 0x0100 0x0 0x 0xB800 0x0 0x0010; I wasn't sure how to reserve the memory (based on your earlier suggestion), so I just narrowed the window. Note that I did not change the PCI hardware registers (maybe the FSL code does?), so the outbound window should still be the whole 512MB. If this isn't viable, perhaps you could explain a bit more how to reserve such a chunk of memory so that the PCI mappings remain the same. Thanks again -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Change in PCI behaviour
On 11/21/2010 10:59 AM, Gary Thomas wrote: On 11/19/2010 02:46 PM, Benjamin Herrenschmidt wrote: On Fri, 2010-11-19 at 08:42 -0700, Gary Thomas wrote: In this case, note that PCI device :00:0c.0 is at 0xc000. This causes problems because it's a truly stupid device that does not work properly at PCI [relative] address 0x. It simply does not respond at that address. Pick anywhere else and it will work fine! Hrm, we used to have a trick avoid giving out the first meg of a bus to avoid that sort of thing, I suppose it got lost. The rest is related to the way you map your PCI I suppose in your dts. You can switch back to a 1:1 instead of 1:0 mapping I suppose. One way to achieve the above result would be to, in your platform code, reserve the mem region that corresponds to PCI 0...1M (c000...+1M) before the device resources are assigned/allocated. I though we had code to do that with the legacy regions somewhere... oh well, no code at hand to check right now. Thanks, I found a combo of regions in my DTS that fixed this. That went well and the system is now running, but it's not stable :-( It will crash randomly, generally leaving no trace of what went wrong. I've attached a BDI to it, but mostly all it can tell me is it's dead The one thing that seems to pop up is it looks like it's jumping into space (aka the wrong place) when doing rfi (this is a guess). I've seen things like the MSR ends up loaded with an address, or similar strangeness. Were there any system level changes during this period (I know it's some time ago) that might have introduced such an instability? It's tough to scan through the diffs and get a feeling for any little details like this. Any ideas or hints greatly appreciated, thanks I have a bit more information on this. I'm pretty sure that the failures are only happening in my SCSI (SATA actually) code. My board (8347ea) has a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28. In 2.6.32, it will run for a while (possibly quite a while), then timeout trying to do a large block write - typically 256 blocks. Once this timeout happens, the SIL controller is stuck and accesses to it will eventually cause the whole system to hang (as above). Was there any major change in how PCI or DMA was handled between 2.6.28 and 2.6.32? Given the ephemeral nature of these failures (multiple runs all eventually fail, but never the same twice), my only hope of fixing it will be to have some ideas what might have changed. Thanks for any ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Change in PCI behaviour
On 11/19/2010 02:46 PM, Benjamin Herrenschmidt wrote: On Fri, 2010-11-19 at 08:42 -0700, Gary Thomas wrote: In this case, note that PCI device :00:0c.0 is at 0xc000. This causes problems because it's a truly stupid device that does not work properly at PCI [relative] address 0x. It simply does not respond at that address. Pick anywhere else and it will work fine! Hrm, we used to have a trick avoid giving out the first meg of a bus to avoid that sort of thing, I suppose it got lost. The rest is related to the way you map your PCI I suppose in your dts. You can switch back to a 1:1 instead of 1:0 mapping I suppose. One way to achieve the above result would be to, in your platform code, reserve the mem region that corresponds to PCI 0...1M (c000...+1M) before the device resources are assigned/allocated. I though we had code to do that with the legacy regions somewhere... oh well, no code at hand to check right now. Thanks, I found a combo of regions in my DTS that fixed this. That went well and the system is now running, but it's not stable :-( It will crash randomly, generally leaving no trace of what went wrong. I've attached a BDI to it, but mostly all it can tell me is it's dead The one thing that seems to pop up is it looks like it's jumping into space (aka the wrong place) when doing rfi (this is a guess). I've seen things like the MSR ends up loaded with an address, or similar strangeness. Were there any system level changes during this period (I know it's some time ago) that might have introduced such an instability? It's tough to scan through the diffs and get a feeling for any little details like this. Any ideas or hints greatly appreciated, thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Change in PCI behaviour
I'm upgrading from 2.6.28 to 2.6.32 (yes, I know it's not the latest, but it's the best I can do at the moment). There seems to have been a change in how the PCI bus is scanned/assigned which is causing me some hardware problems. My hardware is FSL MPC8347 and the problem is likely specific to the FSL PCI code. My system has 256MB RAM, fully mapped into the PCI export window. There are an additional 2 devices on the PCI bus. On 2.6.28, I get this layout: PCI: Probing PCI hardware pci :00:00.0: reg 10 32bit mmio: [0x00-0x0f] pci :00:00.0: reg 18 64bit mmio: [0x00-0xfff] pci :00:0b.0: reg 10 io port: [0x1000-0x1007] pci :00:0b.0: reg 14 io port: [0x1008-0x100b] pci :00:0b.0: reg 18 io port: [0x1010-0x1017] pci :00:0b.0: reg 1c io port: [0x1018-0x101b] pci :00:0b.0: reg 20 io port: [0x1020-0x102f] pci :00:0b.0: reg 24 32bit mmio: [0x10-0x1001ff] pci :00:0b.0: reg 30 32bit mmio: [0x00-0x07] pci :00:0b.0: supports D1 D2 pci :00:0c.0: reg 10 32bit mmio: [0x400-0x7ff] PCI: Cannot allocate resource region 5 of device :00:0b.0, will remap PCI: Cannot allocate resource region 0 of device :00:0c.0, will remap bus: 00 index 0 io port: [0x00-0xf] bus: 00 index 1 mmio: [0xc000-0xdfff] There are no notices, but the key item is that device :00:0c.0 gets mapped at PCI address 0xD000. On 2.6.32, I get this: PCI: Probing PCI hardware pci :00:0b.0: reg 10: [io 0x1000-0x1007] pci :00:0b.0: reg 14: [io 0x1008-0x100b] pci :00:0b.0: reg 18: [io 0x1010-0x1017] pci :00:0b.0: reg 1c: [io 0x1018-0x101b] pci :00:0b.0: reg 20: [io 0x1020-0x102f] pci :00:0b.0: reg 24: [mem 0x0010-0x001001ff] pci :00:0b.0: reg 30: [mem 0x-0x0007 pref] pci :00:0b.0: supports D1 D2 pci :00:0c.0: reg 10: [mem 0x0400-0x07ff] PCI: Cannot allocate resource region 5 of device :00:0b.0, will remap PCI: Cannot allocate resource region 0 of device :00:0c.0, will remap pci :00:0c.0: BAR 0: assigned [mem 0xc000-0xc3ff] pci :00:0c.0: BAR 0: set to [mem 0xc000-0xc3ff] (PCI address [0xc000-0xc3ff] pci :00:0b.0: BAR 6: assigned [mem 0xc400-0xc407 pref] pci :00:0b.0: BAR 5: assigned [mem 0xc408-0xc40801ff] pci :00:0b.0: BAR 5: set to [mem 0xc408-0xc40801ff] (PCI address [0xc408-0xc40801ff] pci_bus :00: resource 0 [io 0x-0xf] pci_bus :00: resource 1 [mem 0xc000-0xdfff] In this case, note that PCI device :00:0c.0 is at 0xc000. This causes problems because it's a truly stupid device that does not work properly at PCI [relative] address 0x. It simply does not respond at that address. Pick anywhere else and it will work fine! On 2.6.28, I get this layout: # ls -l /sys/bus/pci/devices lrwxrwxrwx1 root root 0 Jan 1 1970 :00:00.0 - ../../../devices/pci:00/:00:00.0 lrwxrwxrwx1 root root 0 Jan 1 1970 :00:0b.0 - ../../../devices/pci:00/:00:0b.0 lrwxrwxrwx1 root root 0 Jan 1 1970 :00:0c.0 - ../../../devices/pci:00/:00:0c.0 # cat /sys/bus/pci/devices/\:00\:0c.0/resource 0xd000 0xd3ff 0x00020200 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x On 2.6.32, the final layout looks like this: # ls -l /sys/bus/pci/devices/ lrwxrwxrwx1 root root 0 Jan 1 1970 :00:0b.0 - ../../../devices/pci:00/:00:0b.0 lrwxrwxrwx1 root root 0 Jan 1 1970 :00:0c.0 - ../../../devices/pci:00/:00:0c.0 # cat /sys/bus/pci/devices/\:00\:0c.0/resource 0xc000 0xc3ff 0x00020200 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x Bottom line: how can I get this behaviour back (so as to get my stupid graphics controller working again)?? Thanks for any ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Introduce support for little endian PowerPC
On 10/01/2010 05:30 AM, Josh Boyer wrote: On Fri, Oct 1, 2010 at 5:02 AM, Kumar Galaga...@kernel.crashing.org wrote: On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote: Some PowerPC processors can be run in either big or little endian modes, some others can map selected pages of memory as little endian, which allows the same thing. Until now we have only supported the default big endian mode in Linux. This patch set introduces little endian support for the 44x family of PowerPC processors. From a community aspect is anyone actually going to use this? Is this going to be the equivalent of voyager on x86? I've got nothing against some of the endian clean ups this introduces. However the changes to misc_32.S are a bit ugly from a readability point of view. Just seems like this is likely to bit-rot pretty quickly. I'm with Kumar on this one. Why would we want to support this? I can't say I would be very willing to help anyone run in LE mode, let alone have it randomly selectable. Indeed, I thought we had killed that Windows-NT dog ~15 years ago :-) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Introduce support for little endian PowerPC
On 10/01/2010 06:15 AM, Benjamin Herrenschmidt wrote: On Fri, 2010-10-01 at 05:55 -0600, Gary Thomas wrote: On 10/01/2010 05:30 AM, Josh Boyer wrote: On Fri, Oct 1, 2010 at 5:02 AM, Kumar Galaga...@kernel.crashing.org wrote: On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote: Some PowerPC processors can be run in either big or little endian modes, some others can map selected pages of memory as little endian, which allows the same thing. Until now we have only supported the default big endian mode in Linux. This patch set introduces little endian support for the 44x family of PowerPC processors. From a community aspect is anyone actually going to use this? Is this going to be the equivalent of voyager on x86? I've got nothing against some of the endian clean ups this introduces. However the changes to misc_32.S are a bit ugly from a readability point of view. Just seems like this is likely to bit-rot pretty quickly. I'm with Kumar on this one. Why would we want to support this? I can't say I would be very willing to help anyone run in LE mode, let alone have it randomly selectable. Indeed, I thought we had killed that Windows-NT dog ~15 years ago :-) Actually this has more to do with having to deal with code written for ARM LE :-) The comment was mostly aimed as a remnder of the main reason this was considered a long time ago. I understand that the world has moved on, and sadly the vast majority of hardware is now little endian (although it still baffles me why anyone would think that way...) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Continuing UCC UART woes
I thought I had this working, but it seems to only work for UCC3.
Sadly, I can't get it to work on UCC4/UCC5/UCC8 at all.
Starting with UCC4, I have:
/* ttyQE0 (UCC4) */
serial_qe0: ser...@3200 {
device_type = serial;
compatible = ucc_uart;
cell-index = 4;
reg = 0x3200 0x200;
interrupts = 35;
interrupt-parent = qeic;
port-number = 0;
rx-clock-name = brg9;
tx-clock-name = brg10;
soft-uart;
};
With this setup, I can receive characters from the device, but
no characters ever go out. Same behaviour as before - the output
descriptors get filled, but no action seems to be taken, no interrupts,
etc. Except randomly there will be output! For example, if I
connect to the port with minicom, what I type is received by /dev/ttyQE2.
On some rare occasions, what I type is also echoed back, but when
this happens, it's only the first couple of characters, then nothing.
I verified that the CMXUCR registers are being set per the DTS
as well as the BRG registers. They all look correct:
ucc_set_qe_mux_rxtx - CMX: 0x000a
r...@ppc_target:~ stty /dev/ttyQE0 38400
qe_setbrg - BRG: fddfd660 = 0x000106b6, CLK = 13200, RATE = 9600,
MULTIPLIER = 16
qe_setbrg - BRG: fddfd664 = 0x000106b5, CLK = 13200, RATE = 9600,
MULTIPLIER = 1
qe_setbrg - BRG: fddfd660 = 0x000101aa, CLK = 13200, RATE = 38400,
MULTIPLIER = 16
qe_setbrg - BRG: fddfd664 = 0x00011ada, CLK = 13200, RATE = 38400,
MULTIPLIER = 1
I've also tried this on UCC5 UCC8 which show the identical
behaviour - input works, output does not. I've tried running
with only a single soft UART (UCC4) as well as having all three
configured. No changes seen.
At this point, I'm using the stock driver from 2.6.33.3
One thing I noticed is that the firmware patch seems quite old.
I got the firmware package from http://opensource.freescale.com/firmware/
We were also told (by FreeScale) to look at
https://www.freescale.com/webapp/Download?colCode=QERAMPKG
Looking at these two packages, it's unclear that they match. Certainly
the dates are very different:
[gtho...@hermes 8358]$ ls -l fsl_qe_ucode QERAMPKG
fsl_qe_ucode:
total 16
-rw-rw-r-- 1 gthomas gthomas 5940 2007-12-10 14:39 fsl_qe_ucode_uart_8360_21.bin
-rw-r--r-- 1 gthomas gthomas 7892 2007-11-30 10:14 license.txt
QERAMPKG:
total 972
-rw-rw-r-- 1 gthomas gthomas 132915 2009-04-07 14:04 SlowProtocols_8323rev11.c
-rw-rw-r-- 1 gthomas gthomas 455446 2009-09-16 15:44
Soft_UART_Microcode_Rel_0_1_2.pdf
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:49 Soft_UART_mpc8360_r2.0.h
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8360_r2.1.h
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8568_r1.1.h
-rw-rw-r-- 1 gthomas gthomas 105457 2009-09-16 16:00 SWUART_8360rev20.c
-rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:32 SWUART_8360rev20.srx
-rw-rw-r-- 1 gthomas gthomas 105318 2009-09-16 15:59 SWUART_8360rev21.c
-rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:14 SWUART_8360rev21.srx
Any ideas what I'm doing wrong?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continuing UCC UART woes
On 06/24/2010 06:54 AM, Gary Thomas wrote:
I thought I had this working, but it seems to only work for UCC3.
Sadly, I can't get it to work on UCC4/UCC5/UCC8 at all.
Starting with UCC4, I have:
/* ttyQE0 (UCC4) */
serial_qe0: ser...@3200 {
device_type = serial;
compatible = ucc_uart;
cell-index = 4;
reg = 0x3200 0x200;
interrupts = 35;
interrupt-parent = qeic;
port-number = 0;
rx-clock-name = brg9;
tx-clock-name = brg10;
soft-uart;
};
With this setup, I can receive characters from the device, but
no characters ever go out. Same behaviour as before - the output
descriptors get filled, but no action seems to be taken, no interrupts,
etc. Except randomly there will be output! For example, if I
connect to the port with minicom, what I type is received by /dev/ttyQE2.
On some rare occasions, what I type is also echoed back, but when
this happens, it's only the first couple of characters, then nothing.
I verified that the CMXUCR registers are being set per the DTS
as well as the BRG registers. They all look correct:
ucc_set_qe_mux_rxtx - CMX: 0x000a
r...@ppc_target:~ stty /dev/ttyQE0 38400
qe_setbrg - BRG: fddfd660 = 0x000106b6, CLK = 13200, RATE = 9600,
MULTIPLIER = 16
qe_setbrg - BRG: fddfd664 = 0x000106b5, CLK = 13200, RATE = 9600,
MULTIPLIER = 1
qe_setbrg - BRG: fddfd660 = 0x000101aa, CLK = 13200, RATE = 38400,
MULTIPLIER = 16
qe_setbrg - BRG: fddfd664 = 0x00011ada, CLK = 13200, RATE = 38400,
MULTIPLIER = 1
I've also tried this on UCC5 UCC8 which show the identical
behaviour - input works, output does not. I've tried running
with only a single soft UART (UCC4) as well as having all three
configured. No changes seen.
At this point, I'm using the stock driver from 2.6.33.3
One thing I noticed is that the firmware patch seems quite old.
I got the firmware package from http://opensource.freescale.com/firmware/
We were also told (by FreeScale) to look at
https://www.freescale.com/webapp/Download?colCode=QERAMPKG
Looking at these two packages, it's unclear that they match. Certainly
the dates are very different:
[gtho...@hermes 8358]$ ls -l fsl_qe_ucode QERAMPKG
fsl_qe_ucode:
total 16
-rw-rw-r-- 1 gthomas gthomas 5940 2007-12-10 14:39
fsl_qe_ucode_uart_8360_21.bin
-rw-r--r-- 1 gthomas gthomas 7892 2007-11-30 10:14 license.txt
QERAMPKG:
total 972
-rw-rw-r-- 1 gthomas gthomas 132915 2009-04-07 14:04
SlowProtocols_8323rev11.c
-rw-rw-r-- 1 gthomas gthomas 455446 2009-09-16 15:44
Soft_UART_Microcode_Rel_0_1_2.pdf
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:49
Soft_UART_mpc8360_r2.0.h
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14
Soft_UART_mpc8360_r2.1.h
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14
Soft_UART_mpc8568_r1.1.h
-rw-rw-r-- 1 gthomas gthomas 105457 2009-09-16 16:00 SWUART_8360rev20.c
-rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:32 SWUART_8360rev20.srx
-rw-rw-r-- 1 gthomas gthomas 105318 2009-09-16 15:59 SWUART_8360rev21.c
-rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:14 SWUART_8360rev21.srx
Any ideas what I'm doing wrong?
BTW, I tried converting the Soft_UART_mpc8360_r2.1.h file
to the firmware format. I had to fiddle with the conversion
program a bit because the firmware has version 0.1.2, but I
ended up with a new firmware file. Here's the change I made:
$ diff -u make_qe_firmware.py*
--- make_qe_firmware.py 2010-06-24 07:19:31.0 -0600
+++ make_qe_firmware.py~2010-06-24 07:15:54.0 -0600
@@ -260,7 +260,7 @@
print Unknown SOC model\n
exit(1)
-if not ucode_major and not ucode_minor:
+if not ucode_major:
print Unknown microcode version\n
exit(1)
No change in behaviour :-(
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continuing UCC UART woes
On 06/24/2010 07:38 AM, Chuck Meade wrote: One thing I noticed is that the firmware patch seems quite old. I got the firmware package from http://opensource.freescale.com/firmware/ We were also told (by FreeScale) to look at https://www.freescale.com/webapp/Download?colCode=QERAMPKG Looking at these two packages, it's unclear that they match. Certainly the dates are very different: [gtho...@hermes 8358]$ ls -l fsl_qe_ucode QERAMPKG fsl_qe_ucode: total 16 -rw-rw-r-- 1 gthomas gthomas 5940 2007-12-10 14:39 fsl_qe_ucode_uart_8360_21.bin -rw-r--r-- 1 gthomas gthomas 7892 2007-11-30 10:14 license.txt QERAMPKG: total 972 -rw-rw-r-- 1 gthomas gthomas 132915 2009-04-07 14:04 SlowProtocols_8323rev11.c -rw-rw-r-- 1 gthomas gthomas 455446 2009-09-16 15:44 Soft_UART_Microcode_Rel_0_1_2.pdf -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:49 Soft_UART_mpc8360_r2.0.h -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8360_r2.1.h -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8568_r1.1.h -rw-rw-r-- 1 gthomas gthomas 105457 2009-09-16 16:00 SWUART_8360rev20.c -rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:32 SWUART_8360rev20.srx -rw-rw-r-- 1 gthomas gthomas 105318 2009-09-16 15:59 SWUART_8360rev21.c -rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:14 SWUART_8360rev21.srx Any ideas what I'm doing wrong? Hi Gary, At http://opensource.freescale.com/firmware there is a script make_qe_firmware.py that Timur said would create a firmware binary out of the firmware header file. I have not used this script, since the existing binary worked for me. But I am using only one UCC UART, so you are going beyond what I have done with this firmware. You can try to use that script to create a newer firmware binary from the header in that zip file. Make sure you are using the right one for your silicon rev. As reported, I've done this - no change. You can use strategic printk debugging in the ucc_uart.c driver to determine on the Tx side what is going wrong. For example, after you tell the QE to output chars, wait a bit and printk out the BD. See if the QE is clearing the READY bit in that BD. That will tell you if the QE is even processing the BD or not. I've also done this - the descriptors are set up, never touched by the QE Odd that input always works, output works only very rarely. Also ensure that for all these other UCCs that you are using that the CD, CTS, RTS pins are set up as plain GPIO pins if you do not have them hooked up to actual CD, CTS, RTS signals. If you *are* using HW flow control, probe all the signals to be sure they are all correct. No change whether these pins are configured or not. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
On 06/24/2010 03:20 PM, Timur Tabi wrote: Timur Tabi wrote: I'd say that there are plenty of unknown issues with this driver/hardware. For some reason, QE UART is just unreliable. I've had several people try to use the QE for UART, and almost everyone has problems with it. I finally got in touch with one of the other development teams, and they said that they got QE UART working with the 8569 and the P1021. The reference board we make with the 8568 does not have QE pinned to the UART, so they didn't try to support that. What about 8358? I'm really stuck here - Rx seems to work, but Tx is totally dead... -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
UCC UART
I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.
When I try to send data to the port, there is no output, not
even any interrupts on the device. What I see is that the UART
driver seems to initialize fine and pushes characters into
the output buffers descriptors. However, there are no
interrupts hence it just sits there...
My device tree entry for this device now looks like this:
/* ttyQE0 (UCC3) */
serial_qe0: ser...@4000 {
device_type = serial;
compatible = ucc_uart;
cell-index = 3;
reg = 0x2200 0x200;
interrupts = 34;
interrupt-parent = qeic;
port-number = 0;
rx-clock-name = brg1;
tx-clock-name = brg1;
};
* Are there any known issues with this driver?
* Is there any way to get a handle on why no data is moving?
* Is there some way to tell if the QE even sees the descriptors?
* The driver and documentation mention a soft UART mode for
chips with broken UART hardware. How do I know if my board
has functioning UART hardware?
Note: I have UCC1+UCC2 working great with ethernet.
Thanks for any pointers or ideas
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
On 06/22/2010 09:10 AM, Chuck Meade wrote:
On 06/22/2010 10:55 AM, Gary Thomas wrote:
I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.
When I try to send data to the port, there is no output, not
even any interrupts on the device. What I see is that the UART
driver seems to initialize fine and pushes characters into
the output buffers descriptors. However, there are no
interrupts hence it just sits there...
My device tree entry for this device now looks like this:
/* ttyQE0 (UCC3) */
serial_qe0: ser...@4000 {
device_type = serial;
compatible = ucc_uart;
cell-index =3;
reg =0x2200 0x200;
interrupts =34;
interrupt-parent =qeic;
port-number =0;
rx-clock-name = brg1;
tx-clock-name = brg1;
};
* Are there any known issues with this driver?
* Is there any way to get a handle on why no data is moving?
* Is there some way to tell if the QE even sees the descriptors?
* The driver and documentation mention a soft UART mode for
chips with broken UART hardware. How do I know if my board
has functioning UART hardware?
Note: I have UCC1+UCC2 working great with ethernet.
Thanks for any pointers or ideas
Hi Gary,
According to the errata, it looks like the MPC8358 is subject to
erratum QE_UART6. You'll need to use soft UART mode and load the
microcode patch. Once that is done you will also need to use two
different BRG's, one for tx and one for rx, since the soft UART mode
microcode patch requires them to be set to different rates (I believe
Rx is 16*baud under soft UART mode, and Tx is 1*baud).
As I feared! Can you tell me where/how to get the microcode patch?
Also, I don't know if it matters or not, but you should change your
dts entry ser...@4000 to ser...@2200, just like you recently changed
your reg = to 0x2200.
I did that as soon as I sent this and saw the glaring inconsistency :-)
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
On 06/22/2010 09:28 AM, Chuck Meade wrote: Hi Gary, According to the errata, it looks like the MPC8358 is subject to erratum QE_UART6. You'll need to use soft UART mode and load the microcode patch. Once that is done you will also need to use two different BRG's, one for tx and one for rx, since the soft UART mode microcode patch requires them to be set to different rates (I believe Rx is 16*baud under soft UART mode, and Tx is 1*baud). As I feared! Can you tell me where/how to get the microcode patch? Also, I don't know if it matters or not, but you should change your dts entry ser...@4000 to ser...@2200, just like you recently changed your reg = to 0x2200. I did that as soon as I sent this and saw the glaring inconsistency :-) Thanks Sure. Go to opensource.freescale.com/firmware and download (for your MPC8358) the 8360 soft UART mode microcode patch. You will need to know if your CPU is a 2.0 or 2.1 silicon, since there is a different microcode patch for each. Then in the kernel config I believe I included CONFIG_FW_LOADER and CONFIG_HOTPLUG (one of those may have autoselected the other). Make sure in your ucc_uart.c driver that soft uart mode is enabled. At boot time, the driver will kick off a 10 second timer that will expect the microcode patch to be loaded before the end of that 10 secs. Very early in my boot sequence, I have a startup script send the microcode patch file to the driver through the firmware-loading sysfs entry. But you need to be aware that the UCC number in the sysfs path will be offset by one. Since you are using UCC3, you should use a '2' in the path as shown below. This sequence worked for me (I changed the number for you to '2' in my command sequence, since I use a different UCC): echo 1 /sys/class/firmware/fsl-ucc-uart2/loading cat /root/fsl_qe_ucode_uart_8360_21.bin /sys/class/firmware/fsl-ucc-uart2/data echo 0 /sys/class/firmware/fsl-ucc-uart2/loading Note that the above presupposes you are using the file for silicon 2.1. Also presupposes that you have put the microcode under your rootfs /root directory. Thanks, I'll give this a try. When I download the firmware this way, do I need to follow the directions in Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
On 06/22/2010 09:53 AM, Chuck Meade wrote: Sure. Go to opensource.freescale.com/firmware and download (for your MPC8358) the 8360 soft UART mode microcode patch. You will need to know if your CPU is a 2.0 or 2.1 silicon, since there is a different microcode patch for each. Then in the kernel config I believe I included CONFIG_FW_LOADER and CONFIG_HOTPLUG (one of those may have autoselected the other). Make sure in your ucc_uart.c driver that soft uart mode is enabled. At boot time, the driver will kick off a 10 second timer that will expect the microcode patch to be loaded before the end of that 10 secs. Very early in my boot sequence, I have a startup script send the microcode patch file to the driver through the firmware-loading sysfs entry. But you need to be aware that the UCC number in the sysfs path will be offset by one. Since you are using UCC3, you should use a '2' in the path as shown below. This sequence worked for me (I changed the number for you to '2' in my command sequence, since I use a different UCC): echo 1 /sys/class/firmware/fsl-ucc-uart2/loading cat /root/fsl_qe_ucode_uart_8360_21.bin /sys/class/firmware/fsl-ucc-uart2/data echo 0 /sys/class/firmware/fsl-ucc-uart2/loading Note that the above presupposes you are using the file for silicon 2.1. Also presupposes that you have put the microcode under your rootfs /root directory. Thanks, I'll give this a try. When I download the firmware this way, do I need to follow the directions in Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt I did not do that, and I have it running here. I will say though that I hardcoded the driver to run in soft UART mode. You will need to at least add the appropriate line to your dts to get the driver to operate in Soft UART mode. I hardcoded mine because I had to backport this UCC UART driver to an older Linux kernel, and that kernel was from before dts existed. Add whatever you need to your dts to make it run in soft UART mode and get the firmware loaded. Use two different BRGs for tx and rx. Make sure your BRG choice is valid for your UCC3. I believe that the UCC UART support has not had too much use so far, but I do have it working (in that older kernel after backporting). I've done all this but sadly the behaviour is the same :-( Any ideas what I might be missing? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
On 06/22/2010 12:14 PM, Chuck Meade wrote: I did not do that, and I have it running here. I will say though that I hardcoded the driver to run in soft UART mode. You will need to at least add the appropriate line to your dts to get the driver to operate in Soft UART mode. I hardcoded mine because I had to backport this UCC UART driver to an older Linux kernel, and that kernel was from before dts existed. Add whatever you need to your dts to make it run in soft UART mode and get the firmware loaded. Use two different BRGs for tx and rx. Make sure your BRG choice is valid for your UCC3. I believe that the UCC UART support has not had too much use so far, but I do have it working (in that older kernel after backporting). I've done all this but sadly the behaviour is the same :-( Any ideas what I might be missing? Check your setup of the UCC3 pins for UART mode. Make sure you either have the UCC3 CD, CTS, RTS pins at the correct levels, or deconfigure those pins (set them up as GPIOs). Just verify every pin is properly set up for UCC3. The UCC3 TxD and RxD signals must be set up properly. Only UCC3 RxD and TxD are configured What BRGs did you choose for tx and rx? BRG1 BRG2 Get a scope on the UCC3 tx pin and try to output some chars. See if there is any digital activity on that pin at all. If you are looking at a terminal for output, there are too many things that could be wrong between that tx pin and your display (e.g. level translation issue, null modem issue, baud incompatibility, terminal program set for XON/XOFF or HW flow control and UART not set up compatibly). For now get the probe directly on the CPU's UCC3 Tx pin, output chars and see if there is any activity. We've done all this - nothing on the pins directly at the CPU. This is behaving very much like there is no clock to the device. Is there something special that needs to be done to get the BRGs to work? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
On 06/22/2010 01:01 PM, Chuck Meade wrote: What BRGs did you choose for tx and rx? BRG1 BRG2 OK Get a scope on the UCC3 tx pin and try to output some chars. See if there is any digital activity on that pin at all. If you are looking at a terminal for output, there are too many things that could be wrong between that tx pin and your display (e.g. level translation issue, null modem issue, baud incompatibility, terminal program set for XON/XOFF or HW flow control and UART not set up compatibly). For now get the probe directly on the CPU's UCC3 Tx pin, output chars and see if there is any activity. We've done all this - nothing on the pins directly at the CPU. This is behaving very much like there is no clock to the device. Is there something special that needs to be done to get the BRGs to work? If I was doing this, at this point I would do some strategic printk debugging within ucc_uart.c. You said that you are using 2.6.33.3, so you already have all the fixes in ucc_slow.c that I had to backport to my older kernel. If you question the setup of the BRGs, go to your function that sets them up. I don't know about 2.6.33.3, but in the latest kernel it is qe_setbrg() in qe.c. At the very bottom there is an out_be32(). printk both the address, and the value that is being written to that address. You may need to cast the values to unsigned longs to printk them. I will look at your numbers if you send them to me. In my implemenation (which again was a backport, so this may not apply to you) the BRG writes were off by 4 bytes. But I think that this error was due to the backport -- a logic mismatch I needed to resolve during the port. Also in the current Linux kernel, there is a dependence on the correctness of the brg-frequency property from the dts. Look up above qe_setbrg() at the qe_get_brg_clk() function. Before the return (there are multiple return points) printk the brg_clk being returned. That must be correct for your hardware -- must be the actual brg freq. I assume that you are booting from U-Boot. I believe in modern implementations that U-Boot fills in the brg-frequency in the device tree at boot time. The driver claims to work with either bus-frequency or brg-frequency set. I only had bus-frequency; when I set brg-frequency, it has started to work. Now to test it with a scope to see what else is wrong... BTW, I use RedBoot - being the original author, how could I not? Thanks for the help -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC interactions
On 06/21/2010 01:19 PM, Steven Blakeslee wrote:
I believe the offset for UCC3 is wrong. The usermanual says UCC3's
registers are at 0x2200-0x23FF. 0x4000 is SDMA. Hope that helps.
Looks like that was it (not sure where I got that value from!)
Thanks
-Original Message-
From:
linuxppc-dev-bounces+blakeslees=embeddedplanet@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+blakeslees=embeddedplanet@lists.ozlabs.org] On Behalf Of
Gary
Thomas
Sent: Monday, June 21, 2010 3:00 PM
To: Linux PPC Development
Subject: UCC interactions
I'm running 2.6.33.3 on MPC8358. I have UCC1+UCC2 working fine
for ethernet, but when I add UCC3 as a UART, the network devices
quit working.
Here are my device tree entries:
/* ETH0 (UCC1, MDIO 0x02, RMII) */
enet_eth0: ether...@2000 {
device_type = network;
compatible = ucc_geth;
cell-index =1;
reg =0x2000 0x200;
interrupts =32;
interrupt-parent =qeic;
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock-name = none;
tx-clock-name = clk16;
phy-handle =phy_eth0;
phy-connection-type = rmii;
pio-handle =pio_ucc1;
linux,network-index =0;
};
/* ETH1 (UCC2, MDIO 0x01, GMII) */
enet_eth1: ether...@3000 {
device_type = network;
compatible = ucc_geth;
cell-index =2;
reg =0x3000 0x200;
interrupts =33;
interrupt-parent =qeic;
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock-name = clk4;
tx-clock-name = none;
fixed-link =1 1 1000 0 0;
phy-connection-type = gmii;
pio-handle =pio_ucc2;
linux,network-index =1;
};
/* ttyQE0 (UCC3) */
serial_qe0: ser...@4000 {
device_type = serial;
compatible = ucc_uart;
cell-index =3;
reg =0x4000 0x200;
interrupts =34;
interrupt-parent =qeic;
port-number =0;
rx-clock-name = brg1;
tx-clock-name = brg1;
};
Are there known interactions between these two drivers/ports?
Maybe there's something obviously wrong with my device tree?
Thanks for any ideas/pointers
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=o5LJJcQU009752from=blakesl...@embeddedplanet.com
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Fixed-link PHY question
I'm working with 2.6.33.3 on a MPC8358. I'm trying to get it to talk to a Marvell (DSA) switch which uses special drivers and addressing to act like a PHY. I have this working fine on some older (2.6.28) systems by using a fixed-link PHY descriptor in my device tree (using the TSEC on 8347). The GETH driver calls 'of_phy_connect_fixed_link' which always gives me this error: PHY 0:01 not found net eth1: Could not attach to PHY How can I get the GETH driver to just accept the pseudo PHY connection specified by fixed-link = 1 1 1000 0 0; Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Fixed-link PHY question
On 06/17/2010 11:56 AM, Gary Thomas wrote: I'm working with 2.6.33.3 on a MPC8358. I'm trying to get it to talk to a Marvell (DSA) switch which uses special drivers and addressing to act like a PHY. I have this working fine on some older (2.6.28) systems by using a fixed-link PHY descriptor in my device tree (using the TSEC on 8347). The GETH driver calls 'of_phy_connect_fixed_link' which always gives me this error: PHY 0:01 not found net eth1: Could not attach to PHY How can I get the GETH driver to just accept the pseudo PHY connection specified by fixed-link = 1 1 1000 0 0; Figured it out - my ethernet node in the device tree has to be called 'ethernet' for the fixed PHY emulation to see the fixed-link properties. Seems rather limited, but I don't have time to change it. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Anyone using PowerPC little-endian mode?
On 06/03/2010 06:20 AM, Paul Mackerras wrote: Currently the kernel supports processes running in little-endian mode on machines that have a little-endian mode (as opposed to an endian bit in the TLB entry like most embedded PowerPC processors do, which is a much better idea). Little-endian mode comes in two flavours: so-called PowerPC little-endian mode, which works by swizzling the bottom 3 bits of the address, and true little-endian mode, which actually swaps the order of the bytes read from or written to memory. The classic 32-bit processors (603, 604, 750, 74xx, and derivatives) implemented PowerPC little-endian mode, and I think some early 64-bit processors did also. POWER6 and POWER7 implement true little-endian mode. POWER4, PPC970 and POWER5 don't implement any little-endian mode. Is anyone actually using little-endian mode processes on processors that implement PowerPC little-endian mode? One of the ways that we could make the alignment interrupt handler go faster is by removing the code for address swizzling that we have in order to handle PowerPC little-endian mode. If nobody is actually using it, we should remove it and make the code simpler and faster. I don't know about today, but my recollection is that the only use of little-endian mode on PowerPC was during the early days attempt to run Windows-NT. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem of PowerPc 82xx when using smc
On 05/20/2010 09:33 PM, hellohello wrote:
No, it shouldn't -- rx_bd_base is of type cbd_t *, so the multiplication
already happens as part of pointer arithmetic.
---Yes, you are right. I made a basic mistake.
But now I have another question.
The SMC1 params can be relocated to any offset of the DPRAM on a 64 byte
boundary, not as the SCC1, which must be at 0x8000 offset of the DPRAM.
The SMC1 params base is set at 0x87FC offset of the DPRAM.
So if I want SMC1 params start at 0x200 in DPRAM , I should set 0x200 to the
0x87FC offset of the DPRAM.
I have see this code in u-boot, but I can not find this code in neither
cpm_uart_cpm2.c nor cpm_uart_core.c.
Should I add these code to cpm_uart_core.c?
--dp_mem = cpm_dpram_addr(0x87fc);
--out_be16(dp_mem, SMC1_BASE);
Why are you mucking about with this code at all? SMCx serial certainly
works on every platform I've ever used, 8xx and 8xxx as well.
- Original Message -
From: Scott Woodscottw...@freescale.com
To: hellohellohellohello...@163.com
Cc:linuxppc-dev@lists.ozlabs.org
Sent: Friday, May 21, 2010 1:06 AM
Subject: Re: Problem of PowerPc 82xx when using smc
On Thu, May 20, 2010 at 04:58:27PM +0800, hellohello wrote:
I find a problem in
drivers/serial/cpm_uart/cpm_uart_cpm2.c:
int cpm_uart_allocbuf(struct uart_cpm_port *pinfo, unsigned int is_con)
{
... ...
pinfo-tx_bd_base = pinfo-rx_bd_base + pinfo-rx_nrfifos;
/*The above line should be ：*/
pinfo-tx_bd_base = pinfo-rx_bd_base + sizeof(cbd_t) * pinfo-rx_nrfifos;
No, it shouldn't -- rx_bd_base is of type cbd_t *, so the multiplication
already happens as part of pointer arithmetic.
return 0;
}
Where to get the newest code for kernel?
git.kernel.org
How to know whether it is already patched by anyone else? Just search in this
mail list?
As well as the current git tree.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Initcall ordering
On 04/23/2010 07:24 PM, Wolfram Sang wrote:
Hi Gary,
(adding linux-i2c)
On Fri, Apr 23, 2010 at 09:56:07AM -0600, Gary Thomas wrote:
I'm having trouble with the I2C devices on my 8347 platform.
The problem is that I2C device probe() functions are only called
once, as the I2C bus is being initialized (in this case fsl_i2c_init())
I have 2 devices on this bus, one device gets it's initcall
before fsl_i2c_init, the second one does not :-( This means
that the second device is never probed.
Can you try this patch?
No improvement, I'm afraid.
Boot log with initcall_debug=1 attached. I have 2 devices on I2C-1
0x48 == tsc2007 touch screen controller
0x60 == pca9551 LED controller
You can see that the tsc2007 driver gets initialized before the bus
starts, but the pca9551 driver comes too late and never gets probed :-(
Here's the snippet of my device tree:
i...@3100 {
#address-cells = 1;
#size-cells = 0;
cell-index = 1;
compatible = fsl-i2c;
reg = 0x3100 0x100;
interrupts = 15 0x8;
interrupt-parent = ipic;
dfsrr;
t...@01 {
compatible = ti,tsc2007;
reg = 0x48;
};
l...@01 {
compatible = philips,leds-pca955x;
reg = 0x60;
};
};
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
RedBoot e
Memory - 0x0 0x800 (128MB)
ENET0: local-mac-address - 00:07:d2:01:00:2e
ENET1: local-mac-address - 00:07:d2:01:00:2f
CPU clock-frequency - 0x27c19cc0 (667MHz)
CPU timebase-frequency - 0x4f64b50 (83MHz)
CPU bus-frequency - 0x13d92d40 (333MHz)
zImage starting: loaded at 0x0040 (sp: 0x005d0034)
Allocating 0x3cedb8 bytes for kernel ...
gunzipping (0x - 0x0040d000:0x005ce961)...done 0x3b3c14 bytes
Linux/PowerPC load: console=ttyS0,38400 root=/dev/mtdblock3 rootfstype=jffs2 rw
initcall_debug=1
Finalizing device tree... flat tree at 0x5dc300
Using ASP8347E machine description
Linux version 2.6.28-svn5105 (gtho...@titan) (gcc version 4.3.2
(crosstool-ng-svn_unkn...@20090118.021742) ) #19 Sat Apr 24 08:12:18 MDT 2010
console [udbg0] enabled
setup_arch: bootmem
asp834x_setup_arch()
DB FPGA at fdfee000
Found FSL PCI host bridge at 0xff008500. Firmware bus number: 0-0
PCI host bridge /p...@ff008500 (primary) ranges:
MEM 0xc000..0xcfff - 0xc000
IO 0xb800..0xb80f - 0x
arch: exit
Zone PFN ranges:
DMA 0x - 0x8000
Normal 0x8000 - 0x8000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x - 0x8000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: console=ttyS0,38400 root=/dev/mtdblock3 rootfstype=jffs2
rw initcall_debug=1
IPIC (128 IRQ sources) at fdeeb700
PID hash table entries: 512 (order: 9, 2048 bytes)
clocksource: timebase mult[300c4ce] shift[22] registered
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 125864k/131072k available (3608k kernel code, 5052k reserved, 160k
data, 107k bss, 176k init)
Calibrating delay loop... 166.40 BogoMIPS (lpj=332800)
Mount-cache hash table entries: 512
calling spawn_ksoftirqd+0x0/0x58 @ 1
initcall spawn_ksoftirqd+0x0/0x58 returned 0 after 0 usecs
calling net_ns_init+0x0/0x1a0 @ 1
net_namespace: 288 bytes
initcall net_ns_init+0x0/0x1a0 returned 0 after 3906 usecs
calling sysctl_init+0x0/0x4c @ 1
initcall sysctl_init+0x0/0x4c returned 0 after 0 usecs
calling ksysfs_init+0x0/0xd8 @ 1
initcall ksysfs_init+0x0/0xd8 returned 0 after 0 usecs
calling init_jiffies_clocksource+0x0/0x28 @ 1
initcall init_jiffies_clocksource+0x0/0x28 returned 0 after 0 usecs
calling filelock_init+0x0/0x48 @ 1
initcall filelock_init+0x0/0x48 returned 0 after 0 usecs
calling init_misc_binfmt+0x0/0x5c @ 1
initcall init_misc_binfmt+0x0/0x5c returned 0 after 0 usecs
calling init_script_binfmt+0x0/0x28 @ 1
initcall init_script_binfmt+0x0/0x28 returned 0 after 0 usecs
calling init_elf_binfmt+0x0/0x28 @ 1
initcall init_elf_binfmt+0x0/0x28 returned 0 after 0 usecs
calling random32_init+0x0/0xcc @ 1
initcall random32_init+0x0/0xcc returned 0 after 0 usecs
calling sock_init+0x0/0x84 @ 1
initcall sock_init+0x0/0x84 returned 0 after 0 usecs
calling netlink_proto_init+0x0/0x170 @ 1
NET: Registered protocol family 16
initcall netlink_proto_init+0x0/0x170 returned 0 after 3906
Initcall ordering
I'm having trouble with the I2C devices on my 8347 platform. The problem is that I2C device probe() functions are only called once, as the I2C bus is being initialized (in this case fsl_i2c_init()) I have 2 devices on this bus, one device gets it's initcall before fsl_i2c_init, the second one does not :-( This means that the second device is never probed. What can I do about this? Has the problem been seen before? I can provide more data, as required. note: I'm currently using 2.6.28, but I will be moving to 2.6.32 soon in case it matters, but I'd rather find/understand/fix this in 2.6.28 if possible. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Initcall ordering
On 04/23/2010 09:56 AM, Gary Thomas wrote: I'm having trouble with the I2C devices on my 8347 platform. The problem is that I2C device probe() functions are only called once, as the I2C bus is being initialized (in this case fsl_i2c_init()) I have 2 devices on this bus, one device gets it's initcall before fsl_i2c_init, the second one does not :-( This means that the second device is never probed. What can I do about this? Has the problem been seen before? I can provide more data, as required. note: I'm currently using 2.6.28, but I will be moving to 2.6.32 soon in case it matters, but I'd rather find/understand/fix this in 2.6.28 if possible. A possibly related question: how can I2C devices work as modules when the device address + probe info is in the device tree? Given the behaviour I'm seeing (I2C device probes only happen when the bus is enumerated), how is this supposed to work? ... maybe I'm missing something fundamental? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI on 834x
On 02/24/2010 04:08 PM, Gary Thomas wrote: On 02/24/2010 03:25 PM, Kumar Gala wrote: On Feb 24, 2010, at 4:14 PM, Gary Thomas wrote: On 02/24/2010 01:51 PM, Anton Vorontsov wrote: On Wed, Feb 24, 2010 at 02:26:20PM -0600, Scott Wood wrote: Gary Thomas wrote: Yes, I'm using the exact same kernel with these two different PCI setups (done by the boot loader). Restricting the memory via mem=128M has no effect - the PCI layout is the same. I think the outbound window size is required because of how the Linux PCI remaps the space (note in my dumps that it put the MMIO of the boards starting at 0xD000 when the inbound window is 0x1000) I see where the amount of RAM is mattering -- Linux is assigning outbound I/O space to the PCI controller itself (device 00:00.0) and the amount that it asks for seems to differ based on memory size. Linux ought to skip that device when assigning resources. Some platforms do this (search for pci_exclude_device), but it seems to be missing on 83xx. Actually, 83xx had these exclude_device hooks, but they were removed: commit d8f1324a5063c833862328ceafabc53ac3cc4f71 Author: Kumar Galaga...@kernel.crashing.org Date: Wed Sep 12 22:14:10 2007 -0500 [POWERPC] 83xx: Removed PCI exclude of PHB Now that the generic code doesn't assign resources for Freescale PHBs we dont have to explicitly exclude it. Signed-off-by: Kumar Galaga...@kernel.crashing.org May be the generic code started to assign the resources again? That cracked it; I re-enabled the exclusion of the bridge and now it's all working fine. Thanks for the help Note: I'm working with a fairly old kernel, so these results would have to be reworked against the latest. Odd that the generic code isn't dealing with that for you. Remember it's an old kernel (2.6.28), so who knows the status. As I said, I'll revisit this when I move to a newer kernel. I may have been too hasty pronouncing this fixed. Indeed, the SATA interface now works, but my video card (Fujitsu Coral-P) does not work when it's mapped at the bottom of the PCI space :-( With the bridge mapped, the video ends up at a non-zero address (0xC800..0xCFFF). If it gets mapped to 0xC000, it fails to respond to MMIO accesses. Any ideas how I might get around this? Is there a way to force the PCI allocator to start somewhere other than [relative] zero? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI on 834x
On 02/24/2010 11:48 AM, Scott Wood wrote: Gary Thomas wrote: Does anyone have experience setting up the PCI controller on the MPC8349? I have it running fine when my system has 128MB or less of main memory, but when I have 256MB or more, it all falls apart :-( Any indication of the pertinent settings would be appreciated. Check the inbound PCI translation registers, especially PIWARn. Yes, I set it to 256MB (the size of RAM). I also set PCI_AR0 to a 512MB window (when it's set to 256, I get address [segmentation violation] errors when accessing my devices that end up at the high end of the logical address space) Finally, I set POCMR0 to a 512MB window (corresponding to PCI_AR0) In this configuration, my device doesn't seem to be able to access RAM. If PIWAR1 is too small, the device just hangs. === 128MB setup = PIWAR1 = 0xA0055000 | (27-1) POCMR0 = 0x800F PCIAR0 = 0x8000 | (28-1) 00:00.0 Power PC: Unknown device 1957:0082 (rev 30) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at cc00 (32-bit, non-prefetchable) [size=1M] Memory at c000 (64-bit, prefetchable) [size=128M] Memory at unassigned (64-bit, non-prefetchable) Capabilities: [48] #06 [] 00:0b.0 Mass storage controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) Subsystem: Silicon Image, Inc. SiI 3512 SATALink Controller Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 22 I/O ports at 1000 [size=8] I/O ports at 1008 [size=4] I/O ports at 1010 [size=8] I/O ports at 1018 [size=4] I/O ports at 1020 [size=16] Memory at cc18 (32-bit, non-prefetchable) [size=512] [virtual] Expansion ROM at cc10 [disabled] [size=512K] Capabilities: [60] Power Management version 2 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01) Flags: bus master, medium devsel, latency 0, IRQ 19 Memory at c800 (32-bit, non-prefetchable) [size=64M] = === 256MB setup = PIWAR1 = 0xA0055000 | (28-1) POCMR0 = 0x800E PCIAR0 = 0x8000 | (29-1) 00:00.0 Power PC: Unknown device 1957:0082 (rev 30) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at d400 (32-bit, non-prefetchable) [size=1M] Memory at c000 (64-bit, prefetchable) [size=256M] Memory at unassigned (64-bit, non-prefetchable) Capabilities: [48] #06 [] 00:0b.0 Mass storage controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) Subsystem: Silicon Image, Inc. SiI 3512 SATALink Controller Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 22 I/O ports at 1000 [size=8] I/O ports at 1008 [size=4] I/O ports at 1010 [size=8] I/O ports at 1018 [size=4] I/O ports at 1020 [size=16] Memory at d418 (32-bit, non-prefetchable) [size=512] [virtual] Expansion ROM at d410 [disabled] [size=512K] Capabilities: [60] Power Management version 2 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01) Flags: bus master, medium devsel, latency 0, IRQ 19 [virtual] Memory at d000 (32-bit, non-prefetchable) [size=64M] = Any ideas what I might be missing? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI on 834x
On 02/24/2010 01:51 PM, Anton Vorontsov wrote: On Wed, Feb 24, 2010 at 02:26:20PM -0600, Scott Wood wrote: Gary Thomas wrote: Yes, I'm using the exact same kernel with these two different PCI setups (done by the boot loader). Restricting the memory via mem=128M has no effect - the PCI layout is the same. I think the outbound window size is required because of how the Linux PCI remaps the space (note in my dumps that it put the MMIO of the boards starting at 0xD000 when the inbound window is 0x1000) I see where the amount of RAM is mattering -- Linux is assigning outbound I/O space to the PCI controller itself (device 00:00.0) and the amount that it asks for seems to differ based on memory size. Linux ought to skip that device when assigning resources. Some platforms do this (search for pci_exclude_device), but it seems to be missing on 83xx. Actually, 83xx had these exclude_device hooks, but they were removed: commit d8f1324a5063c833862328ceafabc53ac3cc4f71 Author: Kumar Galaga...@kernel.crashing.org Date: Wed Sep 12 22:14:10 2007 -0500 [POWERPC] 83xx: Removed PCI exclude of PHB Now that the generic code doesn't assign resources for Freescale PHBs we dont have to explicitly exclude it. Signed-off-by: Kumar Galaga...@kernel.crashing.org May be the generic code started to assign the resources again? That cracked it; I re-enabled the exclusion of the bridge and now it's all working fine. Thanks for the help Note: I'm working with a fairly old kernel, so these results would have to be reworked against the latest. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI on 834x
On 02/24/2010 03:25 PM, Kumar Gala wrote: On Feb 24, 2010, at 4:14 PM, Gary Thomas wrote: On 02/24/2010 01:51 PM, Anton Vorontsov wrote: On Wed, Feb 24, 2010 at 02:26:20PM -0600, Scott Wood wrote: Gary Thomas wrote: Yes, I'm using the exact same kernel with these two different PCI setups (done by the boot loader). Restricting the memory via mem=128M has no effect - the PCI layout is the same. I think the outbound window size is required because of how the Linux PCI remaps the space (note in my dumps that it put the MMIO of the boards starting at 0xD000 when the inbound window is 0x1000) I see where the amount of RAM is mattering -- Linux is assigning outbound I/O space to the PCI controller itself (device 00:00.0) and the amount that it asks for seems to differ based on memory size. Linux ought to skip that device when assigning resources. Some platforms do this (search for pci_exclude_device), but it seems to be missing on 83xx. Actually, 83xx had these exclude_device hooks, but they were removed: commit d8f1324a5063c833862328ceafabc53ac3cc4f71 Author: Kumar Galaga...@kernel.crashing.org Date: Wed Sep 12 22:14:10 2007 -0500 [POWERPC] 83xx: Removed PCI exclude of PHB Now that the generic code doesn't assign resources for Freescale PHBs we dont have to explicitly exclude it. Signed-off-by: Kumar Galaga...@kernel.crashing.org May be the generic code started to assign the resources again? That cracked it; I re-enabled the exclusion of the bridge and now it's all working fine. Thanks for the help Note: I'm working with a fairly old kernel, so these results would have to be reworked against the latest. Odd that the generic code isn't dealing with that for you. Remember it's an old kernel (2.6.28), so who knows the status. As I said, I'll revisit this when I move to a newer kernel. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: USB host on 83xx
On 01/27/2010 05:05 PM, Gary Thomas wrote: On 01/27/2010 01:20 PM, Gary Thomas wrote: I have two nearly identical boards, with very different behavior. Older 8347 (PVR: 0x80830011) New 8347 (PVR: 0x80830031) I lied (more precisely I was lied to and I passed it on - I've never seen these boards in person, just worked on them from thousands of miles away). The boards have more than a rev difference: OLD - 8347EA (SVR: 0x80540011, PVR: 0x80830011) NEW - 8343E (SVR: 0x80570030, PVR: 0x80830031) This turned out to be a powerup/strapping issue. This is now fixed and the SVR is 0x80550030 on the failing board. No change in behavior. Does anyone have any ideas about this? Could this have any bearing on the problems? I've tried a number of kernels (vintages) on both with wild results. 2.6.20 - Same kernel works on both(*) 2.6.28 - Kernel runs great on OLD, machine check on NEW 2.6.32.6 - Ditto The problem occurs (only on the new silicon) during the USB host initialization. The root hub is found and initialized, then the EHCI subsystem is reset (to force it to find siblings on the bus). This results in a machine check at the point where the PHY is being reinitialized. I've peppered the driver with messages - here's what I see: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1 ** ehci_fsl_setup.272 ** ehci_fsl_setup.296 ** ehci_fsl_setup.299 ** ehci_fsl_reinit.257 ** mpc83xx_usb_setup.192 ** mpc83xx_usb_setup.207 ** mpc83xx_usb_setup.215 ** mpc83xx_usb_setup.220 ** mpc83xx_setup_phy.163 ** mpc83xx_setup_phy.180 ** mpc83xx_setup_phy.182 ** mpc83xx_usb_setup.238 ** mpc83xx_usb_setup.245 ** mpc83xx_usb_setup.249 ** mpc83xx_usb_setup.251 ** ehci_fsl_reinit.259 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 ** ehci_fsl_reinit.261 ** ehci_fsl_setup.301 fsl-ehci fsl-ehci.0: irq 39, io base 0xff022000 fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found ** ehci_hub_control.559 - req: 40966 ** ehci_hub_control.637 hub 1-0:1.0: 2 ports detected ** ehci_hub_control.559 - req: 40960 ** ehci_hub_control.642 ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 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.28 ehci_hcd usb usb1: SerialNumber: fsl-ehci.0 fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2 ** ehci_fsl_setup.272 ** ehci_fsl_setup.296 ** ehci_fsl_setup.299 ** ehci_fsl_reinit.257 ** mpc83xx_usb_setup.192 ** mpc83xx_usb_setup.207 ** mpc83xx_usb_setup.215 ** mpc83xx_setup_phy.163 ** mpc83xx_setup_phy.180 MACHINE CHECK - so dead it can't even print the message! At this point, it should carry on like this: ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 ** ehci_hub_control.559 - req: 41728 ** ehci_hub_control.648 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 usb 1-1: configuration #1 chosen from 1 choice hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub ** ehci_hub_control.559 - req: 41728 ** ehci_hub_control.648 You can see that it successfully found the connected external HUB. Any ideas why this happens? This [basic] code used to work (2.6.20) on both platforms. I know that's a long time ago, but MACHINE CHECK?? (*) To get this platform to run 2.6.20, I had to patch the CPU tables to recognize it as 8347 (kernels of that vintage relied on the SVR to make choices, not PVR) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: USB host on 83xx
On 01/28/2010 05:17 AM, Gary Thomas wrote: On 01/27/2010 05:05 PM, Gary Thomas wrote: On 01/27/2010 01:20 PM, Gary Thomas wrote: I have two nearly identical boards, with very different behavior. Older 8347 (PVR: 0x80830011) New 8347 (PVR: 0x80830031) I lied (more precisely I was lied to and I passed it on - I've never seen these boards in person, just worked on them from thousands of miles away). The boards have more than a rev difference: OLD - 8347EA (SVR: 0x80540011, PVR: 0x80830011) NEW - 8343E (SVR: 0x80570030, PVR: 0x80830031) This turned out to be a powerup/strapping issue. This is now fixed and the SVR is 0x80550030 on the failing board. No change in behavior. Does anyone have any ideas about this? Even more data; it turns out that after the first write to the USB/DR port status/control register, the processor is dead :-( Using a BDI: ** Dump the USB/DR machine registers asp8347md 0xff023100 ff023100 : 4001 11000100 0600 @... ff023110 : ff023120 : 0100 8601 ff023130 : ff023140 : 0800 ff023150 : ff023160 : 1010 ff023170 : 0008 ff023180 : 0100 0090 ff023190 : ff0231a0 : 2010 ... ff0231b0 : ff0231c0 : 80008000 ff0231d0 : ff0231e0 : ff0231f0 : ** Write to the port status/control register asp8347mm 0xff023184 0x80 ** Display the USB/DR registers asp8347md 0xff023100 # SAP: read access failed This of course works fine on the 1.1 silicon. Could this have any bearing on the problems? I've tried a number of kernels (vintages) on both with wild results. 2.6.20 - Same kernel works on both(*) 2.6.28 - Kernel runs great on OLD, machine check on NEW 2.6.32.6 - Ditto The problem occurs (only on the new silicon) during the USB host initialization. The root hub is found and initialized, then the EHCI subsystem is reset (to force it to find siblings on the bus). This results in a machine check at the point where the PHY is being reinitialized. I've peppered the driver with messages - here's what I see: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1 ** ehci_fsl_setup.272 ** ehci_fsl_setup.296 ** ehci_fsl_setup.299 ** ehci_fsl_reinit.257 ** mpc83xx_usb_setup.192 ** mpc83xx_usb_setup.207 ** mpc83xx_usb_setup.215 ** mpc83xx_usb_setup.220 ** mpc83xx_setup_phy.163 ** mpc83xx_setup_phy.180 ** mpc83xx_setup_phy.182 ** mpc83xx_usb_setup.238 ** mpc83xx_usb_setup.245 ** mpc83xx_usb_setup.249 ** mpc83xx_usb_setup.251 ** ehci_fsl_reinit.259 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 ** ehci_fsl_reinit.261 ** ehci_fsl_setup.301 fsl-ehci fsl-ehci.0: irq 39, io base 0xff022000 fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found ** ehci_hub_control.559 - req: 40966 ** ehci_hub_control.637 hub 1-0:1.0: 2 ports detected ** ehci_hub_control.559 - req: 40960 ** ehci_hub_control.642 ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 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.28 ehci_hcd usb usb1: SerialNumber: fsl-ehci.0 fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2 ** ehci_fsl_setup.272 ** ehci_fsl_setup.296 ** ehci_fsl_setup.299 ** ehci_fsl_reinit.257 ** mpc83xx_usb_setup.192 ** mpc83xx_usb_setup.207 ** mpc83xx_usb_setup.215 ** mpc83xx_setup_phy.163 ** mpc83xx_setup_phy.180 MACHINE CHECK - so dead it can't even print the message! At this point, it should carry on like this: ** ehci_hub_control.559 - req: 8963
USB host on 83xx
I have two nearly identical boards, with very different behavior. Older 8347 (PVR: 0x80830011) New 8347 (PVR: 0x80830031) I've tried a number of kernels (vintages) on both with wild results. 2.6.20 - Same kernel works on both(*) 2.6.28 - Kernel runs great on OLD, machine check on NEW 2.6.32.6 - Ditto The problem occurs (only on the new silicon) during the USB host initialization. The root hub is found and initialized, then the EHCI subsystem is reset (to force it to find siblings on the bus). This results in a machine check at the point where the PHY is being reinitialized. I've peppered the driver with messages - here's what I see: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1 ** ehci_fsl_setup.272 ** ehci_fsl_setup.296 ** ehci_fsl_setup.299 ** ehci_fsl_reinit.257 ** mpc83xx_usb_setup.192 ** mpc83xx_usb_setup.207 ** mpc83xx_usb_setup.215 ** mpc83xx_usb_setup.220 ** mpc83xx_setup_phy.163 ** mpc83xx_setup_phy.180 ** mpc83xx_setup_phy.182 ** mpc83xx_usb_setup.238 ** mpc83xx_usb_setup.245 ** mpc83xx_usb_setup.249 ** mpc83xx_usb_setup.251 ** ehci_fsl_reinit.259 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 ** ehci_fsl_reinit.261 ** ehci_fsl_setup.301 fsl-ehci fsl-ehci.0: irq 39, io base 0xff022000 fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found ** ehci_hub_control.559 - req: 40966 ** ehci_hub_control.637 hub 1-0:1.0: 2 ports detected ** ehci_hub_control.559 - req: 40960 ** ehci_hub_control.642 ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 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.28 ehci_hcd usb usb1: SerialNumber: fsl-ehci.0 fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2 ** ehci_fsl_setup.272 ** ehci_fsl_setup.296 ** ehci_fsl_setup.299 ** ehci_fsl_reinit.257 ** mpc83xx_usb_setup.192 ** mpc83xx_usb_setup.207 ** mpc83xx_usb_setup.215 ** mpc83xx_setup_phy.163 ** mpc83xx_setup_phy.180 MACHINE CHECK - so dead it can't even print the message! At this point, it should carry on like this: ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 ** ehci_hub_control.559 - req: 41728 ** ehci_hub_control.648 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 usb 1-1: configuration #1 chosen from 1 choice hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub ** ehci_hub_control.559 - req: 41728 ** ehci_hub_control.648 You can see that it successfully found the connected external HUB. Any ideas why this happens? This [basic] code used to work (2.6.20) on both platforms. I know that's a long time ago, but MACHINE CHECK?? (*) To get this platform to run 2.6.20, I had to patch the CPU tables to recognize it as 8347 (kernels of that vintage relied on the SVR to make choices, not PVR) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: USB host on 83xx
On 01/27/2010 01:20 PM, Gary Thomas wrote: I have two nearly identical boards, with very different behavior. Older 8347 (PVR: 0x80830011) New 8347 (PVR: 0x80830031) I lied (more precisely I was lied to and I passed it on - I've never seen these boards in person, just worked on them from thousands of miles away). The boards have more than a rev difference: OLD - 8347EA (SVR: 0x80540011, PVR: 0x80830011) NEW - 8343E (SVR: 0x80570030, PVR: 0x80830031) Could this have any bearing on the problems? I've tried a number of kernels (vintages) on both with wild results. 2.6.20 - Same kernel works on both(*) 2.6.28 - Kernel runs great on OLD, machine check on NEW 2.6.32.6 - Ditto The problem occurs (only on the new silicon) during the USB host initialization. The root hub is found and initialized, then the EHCI subsystem is reset (to force it to find siblings on the bus). This results in a machine check at the point where the PHY is being reinitialized. I've peppered the driver with messages - here's what I see: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1 ** ehci_fsl_setup.272 ** ehci_fsl_setup.296 ** ehci_fsl_setup.299 ** ehci_fsl_reinit.257 ** mpc83xx_usb_setup.192 ** mpc83xx_usb_setup.207 ** mpc83xx_usb_setup.215 ** mpc83xx_usb_setup.220 ** mpc83xx_setup_phy.163 ** mpc83xx_setup_phy.180 ** mpc83xx_setup_phy.182 ** mpc83xx_usb_setup.238 ** mpc83xx_usb_setup.245 ** mpc83xx_usb_setup.249 ** mpc83xx_usb_setup.251 ** ehci_fsl_reinit.259 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 ** ehci_fsl_reinit.261 ** ehci_fsl_setup.301 fsl-ehci fsl-ehci.0: irq 39, io base 0xff022000 fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found ** ehci_hub_control.559 - req: 40966 ** ehci_hub_control.637 hub 1-0:1.0: 2 ports detected ** ehci_hub_control.559 - req: 40960 ** ehci_hub_control.642 ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 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.28 ehci_hcd usb usb1: SerialNumber: fsl-ehci.0 fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2 ** ehci_fsl_setup.272 ** ehci_fsl_setup.296 ** ehci_fsl_setup.299 ** ehci_fsl_reinit.257 ** mpc83xx_usb_setup.192 ** mpc83xx_usb_setup.207 ** mpc83xx_usb_setup.215 ** mpc83xx_setup_phy.163 ** mpc83xx_setup_phy.180 MACHINE CHECK - so dead it can't even print the message! At this point, it should carry on like this: ** ehci_hub_control.559 - req: 8963 ** ehci_hub_control.805 ** ehci_hub_control.559 - req: 41728 ** ehci_hub_control.648 ** ehci_hub_control.559 - req: 8961 ** ehci_hub_control.574 usb 1-1: configuration #1 chosen from 1 choice hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub ** ehci_hub_control.559 - req: 41728 ** ehci_hub_control.648 You can see that it successfully found the connected external HUB. Any ideas why this happens? This [basic] code used to work (2.6.20) on both platforms. I know that's a long time ago, but MACHINE CHECK?? (*) To get this platform to run 2.6.20, I had to patch the CPU tables to recognize it as 8347 (kernels of that vintage relied on the SVR to make choices, not PVR) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/14] powerpc: use printk_once
Michael Ellerman wrote:
On Mon, 2009-08-10 at 10:00 +0200, Wolfram Sang wrote:
On Sun, Aug 09, 2009 at 09:53:58PM +0200, Marcin Slusarz wrote:
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@ozlabs.org
---
arch/powerpc/kernel/iommu.c |6 +-
arch/powerpc/kernel/irq.c|5 ++---
arch/powerpc/sysdev/ppc4xx_pci.c |9 ++---
3 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index fd51578..c7fa258 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -502,7 +502,6 @@ static void iommu_table_clear(struct iommu_table *tbl)
struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
{
unsigned long sz;
- static int welcomed = 0;
struct page *page;
/* Set aside 1/4 of the table for large allocations. */
@@ -523,11 +522,8 @@ struct iommu_table *iommu_init_table(struct
iommu_table *tbl, int nid)
iommu_table_clear(tbl);
- if (!welcomed) {
- printk(KERN_INFO IOMMU table initialized, virtual merging
%s\n,
+ printk_once(KERN_INFO IOMMU table initialized, virtual merging %s\n,
novmerge ? disabled : enabled);
- welcomed = 1;
- }
return tbl;
}
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index f7f376e..05ebd21 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -231,7 +231,6 @@ skip:
void fixup_irqs(cpumask_t map)
{
unsigned int irq;
- static int warned;
for_each_irq(irq) {
cpumask_t mask;
@@ -246,8 +245,8 @@ void fixup_irqs(cpumask_t map)
}
if (irq_desc[irq].chip-set_affinity)
irq_desc[irq].chip-set_affinity(irq, mask);
- else if (irq_desc[irq].action !(warned++))
- printk(Cannot set affinity for irq %i\n, irq);
+ else if (irq_desc[irq].action)
+ printk_once(Cannot set affinity for irq %i\n, irq);
Maybe we should add a loglevel to this printk (and the other one in fix_irqs)
while we are here?
I think you should drop it, it's stupid. If we actually care about irqs
that don't have a set affinity we should keep a count and report that at
the end of the loop.
In addition, this change would prevent reporting missing
affinity on more than one IRQ if there were such.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
Mikhail Zaturenskiy wrote: On Thu, Jul 2, 2009 at 2:10 AM, Frank Svendsbøefrank.svends...@gmail.com wrote: On Wed, Jul 1, 2009 at 10:14 PM, Mikhail Zaturenskiymzaturenskiy...@gmail.com wrote: Hmm... according to Kernel command line: console=ttyCPM0,9600n8 loglevel=7 you haven't specified where root is. Add root=/dev/ram to the kernel command line, and specify where the init process is located (for instance init=/sbin/init). I haven't tried Denks ramdisk image. You can create one for yourself using dd, gzip and U-Boots mkimage tool. If the ramdisk image is larger than 4MB, you must either change the default CONFIG_BLK_DEV_RAM_SIZE=4096, or set ramdisk size in the kernel command line. Btw, I use an older kernel than you use, but I have these defined: CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 Maybe they're obsolete now, but you can try to add them to your defconfig file. Good luck ;-) Thanks Frank, this seems to be leading me down the right path. I tried some of those defines out yesterday and they got the kernel to at least attempt to load the ramdisk, so I'm getting somewhere. Also added root=/dev/ram (also tried /dev/ram0) and init=/sbin/init but for now things are failing before processing those args. I haven't tried CONFIG_BLK_DEV or CONFIG_BLK_DEV_LOOP and am still playing around with the values for CONFIG_BLK_DEV_RAM_COUNT and CONFIG_BLK_DEV_RAM_SIZE. Strangely, the DEV_RAM defines are completely missing from my config so I have to put them in manually... (as opposed to via menuconfig). I'll post back when it's working or when I've tried all of this and still am getting some error. If you don't have CONFIG_BLK_DEV defined, you can't have CONFIG_BLK_DEV_RAM_COUNT or CONFIG_BLK_DEV_RAM_SIZE. Use 'menuconfig' to help straighten this out. Meanwhile a side question - why does BLK_DEV_RAM_COUNT default to 16? This is just the number of unique RAM disk devices supported. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Trouble Transferring control to Linux (at address 00000000)
... 16.12 BogoMIPS (lpj=80640)? 4Mount-cache h??sh table entries: 512? 6net_namespace: 296 bytes? 6NET: Registered protocol f??mily 16? 4bio: create slab bio-0 at 0? 7Switched to high resolution mode on??CPU 0? 6NET: Registered protocol family 2? 6IP route cache hash table entries?? 1024 (order: 0' 4096 bytes)? 6TCP established hash table entries: 2048 (order?? 2' 16384 bytes)? 6TCP bind hash table entries: 2048 (order: 1' 8192 bytes)? 6??TCP: Hash tables configured (established 2048 bind 2048)? 6TCP reno registered?? 6NET: Registered protocol family 1? 6msgmni has been set to 122? 6io schedu??er noop registered? 6io scheduler deadline registered (default)? 6Generic RTC??Driver v1.07? 7irq: irq 4 on host /s...@f000/c...@9c0/interrupt-control...@9??0 mapped to virtual irq 19? 6fa80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq ?? 19) is a CPM UART? 7irq: irq 29 on host /s...@f000/c...@9c0/interrupt-contr??l...@930 mapped to virtual irq 29? 6fa20.serial: ttyCPM1 at MMIO 0xc501aa2?? (irq = 29) is a CPM UART? 7irq: irq 3 on host /s...@f000/interrupt-control?...@0 mapped to virtual irq 20? 6eth0: fs_enet: 00:00:00:00:00:00? 7irq: irq 7??on host /s...@f000/interrupt-control...@0 mapped to virtual irq 21? 6eth1: ??s_enet: 00:00:00:00:00:00? 6FEC MII Bus: probed? 6fe00.flash: Found 2 x16??devices at 0x0 in 32-bit bank? 4 Amd/Fujitsu Extended Query Table at 0x0040? 4??fe00.flash: CFI does not contain boot bank location. Assuming top.? 5numbe?? of CFI chips: 1? 5cfi_cmdset_0002: Disabling erase-suspend-program due to cod?? brokenness.? 6TCP cubic registered? 6NET: Registered protocol family 17? 6R??C: Registered udp transport module.? 6RPC: Registered tcp transport module.? 3??Root-NFS: No NFS server available' giving up.? 3VFS: Unable to mount root fs v??a NFS' trying floppy.? 4VFS: Cannot open root device NULL or unknown-block??2'0)? 4Please append a correct root= boot option; here are the available par??itions:? 41f00 32768 mtdblock0 driver: of-flash? 0Kernel panic - no?? syncing: VFS: Unable to mount root fs on unknown-block(2'0)? 4Call Trace:? 4??c381fed0] [c00069e0] show_stack+0x44/0x16c (unreliable)? 4[c381ff10] [c001bc6c?? panic+0x8c/0x168? 4[c381ff60] [c01ecb80] mount_block_root+0x12c/0x244? 4[c38??ffb0] [c01ecdf4] prepare_namespace+0x4c/0x1c4? 4[c381ffd0] [c01ec1b0] kernel_i??it+0xd0/0xfc? 4[c381fff0] [c000da60] kernel_thread+0x4c/0x68? 0Rebooting in 1??0 seconds..? At this point, my primary goal is to get console output working before I do anything else. I've tried different console=x boot arguments and I've added the chosen section to my DTS, but still no output. Anyone have suggestions about this? Is something else messed up in my DTS? Did you try 'root=ttyCPM0,9600'? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Weird 5200/mtd-ram problem
Albrecht Dreß wrote:
Hi all,
I ran into a weird problem when I tried to access a static (NV) ram attached
to the localbus of a '5200 using Wolfram's mtd-ram OF driver (on a stock
2.6.29.1 kernel). The 512k ram chip is connected in 16-bit mode to cs1. the
of entry reads
nv...@1,0 {
compatible = mtd-ram;
reg = 1 0x0 0x0008; // 512 kB
bank-width = 2;
device-width = 2;
#size-cells = 1;
#address-cells = 1;
};
For the test I created a pattern file which is filled with the unsigned
long 0x0055aaff. Using the Abatron BDI3000, I can write the pattern file to
the ram and re-read it without problems. The same applies to u-boot (write
ram via tftp, dump contents).
In Linux, when I write the file to /dev/mtdx, the last dword of each block is
broken, e.g. when running dd if=pattern of=/dev/mtd5 bs=512 the dword's at
offset 0x1fc, 0x3fc, ... are 0x (instead of 0x0055aaff), if I use
bs=1024 the dwords at 0x3fc, 0x7fc, ... show this value, if I use bs=4096 the
dword at 0xffc shows this value, etc. I looked at the CS/WR lines with a
scope, and I couldn't see anything special. The timing should be fine, as
u-boot uses the same as Linux.
Any idea what goes wrong here? I guessed I missed something in the LPB
setup...
Check your cache setup - the BDI is most certainly not accessing
this via the Data cache whereas Linux probably will be.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Weird 5200/mtd-ram problem
Albrecht Dreß wrote: Am 20.05.09 16:23 schrieb(en) Gary Thomas: In Linux, when I write the file to /dev/mtdx, the last dword of each block is broken, e.g. when running dd if=pattern of=/dev/mtd5 bs=512 the dword's at offset 0x1fc, 0x3fc, ... are 0x (instead of 0x0055aaff), if I use bs=1024 the dwords at 0x3fc, 0x7fc, ... show this value, if I use bs=4096 the dword at 0xffc shows this value, etc. I looked at the CS/WR lines with a scope, and I couldn't see anything special. The timing should be fine, as u-boot uses the same as Linux. Any idea what goes wrong here? I guessed I missed something in the LPB setup... Check your cache setup - the BDI is most certainly not accessing this via the Data cache whereas Linux probably will be. Hmm, yes - I didn't touch the vanilla Lite5200B Linux setup there, which has a flash chip at cs1... If it is really a cache problem (I'm away now from my test board) - isn't a sync sufficient after doing the copy to the external ram (lpb/cs1)? What is the proper approach for devices attached to the localbus? Based on the behaviour, it's probably a timing problem with multi-beat transfers. When the PowerPC does cache flushes, the chip activity is very different than the single beat accesses used by the BDI. Try to access this without using the cache. If it works properly then you'll need to look at the timing setup (the local bus registers) to see why it fails with the multi-beat accesses. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using archaic I2C with OF
Wolfram Sang wrote: Post this on the i2c list. Jean has made an effort to convert all drivers. He must have missed that one. What Jean did was converting all drivers who used the legacy i2c-binding to use the new binding which is a lot better suited to the driver model. The above mentioned driver already uses the new binding. The problem coming up here is another issue and also long standing and not yet solved. There are drivers which require platform_data with function pointers. You cannot encode function pointers to the device tree. One solution is to create a custom driver for your board with the needed specific function and create a platform device from there. Sometimes it works to add a bit more info to the device tree (e.g. some gpios) and parse it via an of_wrapper around the platform driver. So somehow, I need to create a platform driver, possibly inside an of_wrapper, which eventually instantiates an I2C device on a particular bus, with my specific platform data. Sorry, but I'm lost here. How do I untangle this maze of twisty little passages? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Using archaic I2C with OF
I'd like to use an existing I2C driver (a touchscreen device) with my 834x based platform. How do I arrange to provide platform data (i2c_client-dev.platform_data) from my OF world? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using archaic I2C with OF
Jon Smirl wrote: On Fri, May 1, 2009 at 10:39 AM, Jon Smirl jonsm...@gmail.com wrote: On Fri, May 1, 2009 at 9:04 AM, Gary Thomas g...@mlbassoc.com wrote: I'd like to use an existing I2C driver (a touchscreen device) with my 834x based platform. How do I arrange to provide platform data (i2c_client-dev.platform_data) from my OF world? It is easier to convert the i2c driver to work in the current model. All in-tree drivers have already been converted. I'm looking at drivers/input/touchscreen/tsc2007.c (the one I need) from Kumar's 'next' tree. It most definitely still uses the old model. Can you suggest another place to look? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using archaic I2C with OF
Wolfram Sang wrote: Post this on the i2c list. Jean has made an effort to convert all drivers. He must have missed that one. What Jean did was converting all drivers who used the legacy i2c-binding to use the new binding which is a lot better suited to the driver model. The above mentioned driver already uses the new binding. The problem coming up here is another issue and also long standing and not yet solved. There are drivers which require platform_data with function pointers. You cannot encode function pointers to the device tree. One solution is to create a custom driver for your board with the needed specific function and create a platform device from there. Sometimes it works to add a bit more info to the device tree (e.g. some gpios) and parse it via an of_wrapper around the platform driver. Pretty much as I expected. Are there examples of how to do this? In particular how to correlate a GPIO (with interrupt) to another (I2C) device? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
Kumar Gala wrote:
On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote:
Kumar Gala wrote:
On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
I found the difference - in 2.6.28 the inbound/outbound windows
don't seem to be set up at all. In 2.6.26, the function
'fsl_add_bridge'
was common among architectures and ended up calling 'setup_pci_atmu'
which created those mappings. In 2.6.28, the 83xx PCI setup code
has been refactored. It uses 'mpc83xx_add_bridge' instead of
'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
I'm sure this is the problem.
Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code
calling setup_pci_atmu().
It did not directly; it called 'fsl_add_bridge' which in turn called
'setup_pci_atmu'
Don't ever see 83xx boards calling fsl_add_bridge -- that is 85xx/86xx
only in 83xx.
Sorry, you're correct. I got lost looking through the code :-(
No matter, none of that code seems to be relevant to the change
in behaviour.
I modified the 2.6.28 driver to also call this function. Now the
inbound/outbound windows are set up, but the bridge still has
no allocations, so the problem remains.
I need to move on; I may just live with sliding the PCI space
up for now (doesn't really hurt anything, just seems like a hack)
It is and you are glossing over a real bug.
I have found the culprit - in arch/powerpc/kernel/pci_32.c
static void
fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev-class 8;
#if 0
if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
class == PCI_CLASS_BRIDGE_OTHER)
#else
if ((class == PCI_CLASS_PROCESSOR_POWERPC)
#endif
(dev-hdr_type == PCI_HEADER_TYPE_NORMAL)
(dev-bus-parent == NULL)) {
for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
dev-resource[i].start = 0;
dev-resource[i].end = 0;
dev-resource[i].flags = 0;
}
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID,
fixup_hide_host_resource_fsl);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
fixup_hide_host_resource_fsl);
This function is now (the #if 0 case is in 2.6.28) tossing out
the memory resources used by the PCI bridge itself. This makes
everything fall over, at least on my 834x platform.
This change was applied 2008-10-08, but it seems incorrect on the 834x.
Are you using u-boot to boot? If so is the board port public?
My systems use RedBoot (I'm the original author of RedBoot, so one would
expect that). At this moment, the code isn't public, sorry.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
---BeginMessage---
The class of the MPC5121 pci host bridge is PCI_CLASS_BRIDGE_OTHER
while other freescale host bridges have class set to
PCI_CLASS_PROCESSOR_POWERPC.
This patch makes fixup_hide_host_resource_fsl match
PCI_CLASS_BRIDGE_OTHER in addition to PCI_CLASS_PROCESSOR_POWERPC.
Signed-off-by: John Rigby jri...@freescale.com
---
arch/powerpc/kernel/pci_32.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 174b77e..a848c63 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -54,11 +54,12 @@ LIST_HEAD(hose_list);
static int pci_bus_count;
static void
-fixup_hide_host_resource_fsl(struct pci_dev* dev)
+fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev-class 8;
- if ((class == PCI_CLASS_PROCESSOR_POWERPC)
+ if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
+class == PCI_CLASS_BRIDGE_OTHER)
(dev-hdr_type == PCI_HEADER_TYPE_NORMAL)
(dev-bus-parent == NULL)) {
for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
--
1.5.6.2.255.gbed62
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
---End Message---
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
Kumar Gala wrote:
On Apr 23, 2009, at 9:24 AM, Gary Thomas wrote:
I have found the culprit - in arch/powerpc/kernel/pci_32.c
static void
fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev-class 8;
#if 0
if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
class == PCI_CLASS_BRIDGE_OTHER)
#else
if ((class == PCI_CLASS_PROCESSOR_POWERPC)
#endif
(dev-hdr_type == PCI_HEADER_TYPE_NORMAL)
(dev-bus-parent == NULL)) {
for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
dev-resource[i].start = 0;
dev-resource[i].end = 0;
dev-resource[i].flags = 0;
}
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID,
fixup_hide_host_resource_fsl);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
fixup_hide_host_resource_fsl);
This function is now (the #if 0 case is in 2.6.28) tossing out
the memory resources used by the PCI bridge itself. This makes
everything fall over, at least on my 834x platform.
This change was applied 2008-10-08, but it seems incorrect on the 834x.
Its not. The PCI subsystem shouldn't be allocating or seeing the PHBs
resources.
Are you using u-boot to boot? If so is the board port public?
My systems use RedBoot (I'm the original author of RedBoot, so one would
expect that). At this moment, the code isn't public, sorry.
Ok. Not sure if RedBoot has a simple memory dump command, but if you
can dump the IMMR registers for PCI (0x8400 - IOS and 0x8500 - PCI1).
(I'm assuming PCI1 is the one you are using). From IOS I wanted the
I don't think any of this matters. It turns out that even
the 2.6.26 kernel fails on an identical board with a newer
revision of the 8347 chip. I'm sure that the problem is
that the Coral-P fails when mapped to 0 (PCI relative).
I couldn't find another reliable way to get the Coral-P assigned
an address other than 0, so I'm happy accepting the work around
of allowing the kernel to map those windows, even if it's not
necessary.
For completeness, here are the values you asked for:
pcilawbar0 : 0xc000 -1073741824
pcilawar : 0x801b -2147483621
pcilawbar1 : 0xb800 -1207959552
pcilawar1 : 0x8013 -2147483629
8347md 0xff008400
ff008400 : 000c
ff008410 : 800f
ff008420 : 000b8000 c00fff00
ff008430 :
ff008440 :
ff008450 :
ff008460 :
ff008470 :
ff008480 :
ff008490 :
ff0084a0 :
ff0084b0 :
ff0084c0 :
ff0084d0 :
ff0084e0 :
ff0084f0 : 0001 00010006
8347md 0xff008500
ff008500 :
ff008510 :
ff008520 : 0001 0001
ff008530 :
ff008540 :
ff008550 :
ff008560 : a005501a ..P.
ff008570 :
ff008580 :
ff008590 :
ff0085a0 :
ff0085b0 :
ff0085c0 :
ff0085d0 :
ff0085e0 :
ff0085f0 :
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
PCI changes 2.6.26 = 2.6.28
I had a stable port of 2.6.26 for my 834x hardware, with a frame buffer on a PCI device. After I upgraded to 2.6.28, this isn't working any more. The frame buffer code is happily writing to a mapped [memory] space on the PCI card, but nothing is happening. Did something [subtle] change in how the PCI is handled in this timeframe? Perhaps with how PCI devices are mapped or enabled? I've looked at the changes between the two versions, but nothing leaps out at me. n.b. I have other devices on the PCI bus, such as a SATA controller, which work the same in both versions. Thanks for any ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
Gary Thomas wrote: I had a stable port of 2.6.26 for my 834x hardware, with a frame buffer on a PCI device. After I upgraded to 2.6.28, this isn't working any more. The frame buffer code is happily writing to a mapped [memory] space on the PCI card, but nothing is happening. Did something [subtle] change in how the PCI is handled in this timeframe? Perhaps with how PCI devices are mapped or enabled? I've looked at the changes between the two versions, but nothing leaps out at me. n.b. I have other devices on the PCI bus, such as a SATA controller, which work the same in both versions. Thanks for any ideas The difference seems to be in how the PCI bus gets mapped. In the working, 2.6.26 based kernel, 'lspci -v' shows this: 00:00.0 Bridge: Unknown device 1957:0084 (rev 11) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at cc00 (32-bit, non-prefetchable) [size=1M] Memory at c000 (64-bit, prefetchable) [size=128M] Memory at cc143100 (64-bit, non-prefetchable) [size=1] Capabilities: [48] #06 [] 00:0a.0 Network controller: Unknown device 001c:0001 (rev 02) Subsystem: Unknown device 001c:0004 Flags: medium devsel, IRQ 22 Memory at cc12 (32-bit, non-prefetchable) [size=64K] Memory at cc13 (32-bit, non-prefetchable) [size=64K] 00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. Unknown device 3573 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 23 I/O ports at 1000 [size=128] I/O ports at 1100 [size=256] Memory at cc14 (32-bit, non-prefetchable) [size=4K] Memory at cc10 (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01) Flags: bus master, medium devsel, latency 0, IRQ 24 Memory at c800 (32-bit, non-prefetchable) [size=64M] 00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc141000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc142000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.2 USB Controller: Philips Semiconductors USB 2.0 Host Controller (rev 11) (prog-if 20 [EHCI]) Subsystem: Philips Semiconductors USB 2.0 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc143000 (32-bit, non-prefetchable) [size=256] Capabilities: [dc] Power Management version 2 This is what 2.6.28 shows: 00:00.0 Bridge: Unknown device 1957:0084 (rev 11) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at unassigned (64-bit, prefetchable) Memory at unassigned (64-bit, non-prefetchable) Capabilities: [48] #06 [] 00:0a.0 Network controller: Unknown device 001c:0001 (rev 02) Subsystem: Unknown device 001c:0004 Flags: medium devsel, IRQ 16 Memory at c402 (32-bit, non-prefetchable) [size=64K] Memory at c403 (32-bit, non-prefetchable) [size=64K] 00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. Unknown device 3573 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 21 I/O ports at 1000 [size=128] I/O ports at 1100 [size=256] Memory at c404 (32-bit, non-prefetchable) [size=4K] Memory at c400 (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01) Flags: bus master, medium devsel, latency 0, IRQ 22 [virtual] Memory at c000 (32-bit, non-prefetchable) [size=64M] 00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at c4041000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at c4042000 (32-bit, non-prefetchable) [size=4K
Re: PCI changes 2.6.26 = 2.6.28
Gary Thomas wrote: Gary Thomas wrote: I had a stable port of 2.6.26 for my 834x hardware, with a frame buffer on a PCI device. After I upgraded to 2.6.28, this isn't working any more. The frame buffer code is happily writing to a mapped [memory] space on the PCI card, but nothing is happening. Did something [subtle] change in how the PCI is handled in this timeframe? Perhaps with how PCI devices are mapped or enabled? I've looked at the changes between the two versions, but nothing leaps out at me. n.b. I have other devices on the PCI bus, such as a SATA controller, which work the same in both versions. Thanks for any ideas The difference seems to be in how the PCI bus gets mapped. In the working, 2.6.26 based kernel, 'lspci -v' shows this: 00:00.0 Bridge: Unknown device 1957:0084 (rev 11) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at cc00 (32-bit, non-prefetchable) [size=1M] Memory at c000 (64-bit, prefetchable) [size=128M] Memory at cc143100 (64-bit, non-prefetchable) [size=1] Capabilities: [48] #06 [] 00:0a.0 Network controller: Unknown device 001c:0001 (rev 02) Subsystem: Unknown device 001c:0004 Flags: medium devsel, IRQ 22 Memory at cc12 (32-bit, non-prefetchable) [size=64K] Memory at cc13 (32-bit, non-prefetchable) [size=64K] 00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. Unknown device 3573 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 23 I/O ports at 1000 [size=128] I/O ports at 1100 [size=256] Memory at cc14 (32-bit, non-prefetchable) [size=4K] Memory at cc10 (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01) Flags: bus master, medium devsel, latency 0, IRQ 24 Memory at c800 (32-bit, non-prefetchable) [size=64M] 00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc141000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc142000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.2 USB Controller: Philips Semiconductors USB 2.0 Host Controller (rev 11) (prog-if 20 [EHCI]) Subsystem: Philips Semiconductors USB 2.0 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc143000 (32-bit, non-prefetchable) [size=256] Capabilities: [dc] Power Management version 2 This is what 2.6.28 shows: 00:00.0 Bridge: Unknown device 1957:0084 (rev 11) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at unassigned (64-bit, prefetchable) Memory at unassigned (64-bit, non-prefetchable) Capabilities: [48] #06 [] 00:0a.0 Network controller: Unknown device 001c:0001 (rev 02) Subsystem: Unknown device 001c:0004 Flags: medium devsel, IRQ 16 Memory at c402 (32-bit, non-prefetchable) [size=64K] Memory at c403 (32-bit, non-prefetchable) [size=64K] 00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. Unknown device 3573 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 21 I/O ports at 1000 [size=128] I/O ports at 1100 [size=256] Memory at c404 (32-bit, non-prefetchable) [size=4K] Memory at c400 (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01) Flags: bus master, medium devsel, latency 0, IRQ 22 [virtual] Memory at c000 (32-bit, non-prefetchable) [size=64M] 00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at c4041000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master
Re: PCI changes 2.6.26 = 2.6.28
Kumar Gala wrote: On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote: The [two] big differences I see are that the video card (00:0d.0) is being assigned 0xC000, which lspci marks as virtual. I think I've had trouble in the past with memory regions which started at 0 relative to the PCI space. Also virtual concerns me. Does this spark any ideas from anyone? Doesn't ring any bells. What does cat /proc/iomem look like between the two kernels. About what I gleaned from lspci. The working 2.6.26 kernel has space mapped in the controller (exposed memory window, I think) and the video card got moved down accordingly. -- 2.6.26 c000-cfff : /p...@ff008500 c000-c7ff : :00:00.0 c800-cbff : :00:0c.0 c800-cbff : CoralP_fb cc00-cc0f : :00:00.0 cc10-cc11 : :00:0b.0 cc12-cc12 : :00:0a.0 cc13-cc13 : :00:0a.0 cc14-cc140fff : :00:0b.0 cc14-cc140fff : sata_promise cc141000-cc141fff : :00:0d.0 cc141000-cc141fff : ohci_hcd cc142000-cc142fff : :00:0d.1 cc142000-cc142fff : ohci_hcd cc143000-cc1430ff : :00:0d.2 cc143000-cc1430ff : ehci_hcd cc143100-cc143100 : :00:00.0 f000-f1ff : f000.flash ff000200-ff0002ff : wdt ff003000-ff0030ff : i2c ff003100-ff0031ff : i2c ff004500-ff004507 : serial ff004600-ff004607 : serial ff022000-ff022fff : usb ff022000-ff022fff : ehci_hcd ff023000-ff023fff : usb ff023000-ff023fff : usb ff023000-ff023fff : ehci_hcd ff024000-ff024fff : ethernet ff024520-ff02453f : mdio ff025000-ff025fff : ethernet -- 2.6.28 c000-cfff : /p...@ff008500 c000-c3ff : :00:0c.0 c000-c3ff : CoralP_fb c400-c401 : :00:0b.0 c402-c402 : :00:0a.0 c403-c403 : :00:0a.0 c404-c4040fff : :00:0b.0 c404-c4040fff : sata_promise c4041000-c4041fff : :00:0d.0 c4041000-c4041fff : ohci_hcd c4042000-c4042fff : :00:0d.1 c4042000-c4042fff : ohci_hcd c4043000-c40430ff : :00:0d.2 c4043000-c40430ff : ehci_hcd f000-f1ff : f000.flash ff004500-ff004507 : serial ff004600-ff004607 : serial ff022000-ff022fff : usb ff022000-ff022fff : ehci_hcd ff023000-ff023fff : usb ff023000-ff023fff : usb ff023000-ff023fff : ehci_hcd ff024000-ff024fff : ethernet ff024520-ff02453f : mdio ff025000-ff025fff : ethernet I'm still looking into how the PCI address register for the video card did not get written, even though the system obviously thinks it did (hence virtual) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
Gary Thomas wrote: Kumar Gala wrote: On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote: The [two] big differences I see are that the video card (00:0d.0) is being assigned 0xC000, which lspci marks as virtual. I think I've had trouble in the past with memory regions which started at 0 relative to the PCI space. Also virtual concerns me. Does this spark any ideas from anyone? Doesn't ring any bells. What does cat /proc/iomem look like between the two kernels. About what I gleaned from lspci. The working 2.6.26 kernel has space mapped in the controller (exposed memory window, I think) and the video card got moved down accordingly. -- 2.6.26 c000-cfff : /p...@ff008500 c000-c7ff : :00:00.0 c800-cbff : :00:0c.0 c800-cbff : CoralP_fb cc00-cc0f : :00:00.0 cc10-cc11 : :00:0b.0 cc12-cc12 : :00:0a.0 cc13-cc13 : :00:0a.0 cc14-cc140fff : :00:0b.0 cc14-cc140fff : sata_promise cc141000-cc141fff : :00:0d.0 cc141000-cc141fff : ohci_hcd cc142000-cc142fff : :00:0d.1 cc142000-cc142fff : ohci_hcd cc143000-cc1430ff : :00:0d.2 cc143000-cc1430ff : ehci_hcd cc143100-cc143100 : :00:00.0 f000-f1ff : f000.flash ff000200-ff0002ff : wdt ff003000-ff0030ff : i2c ff003100-ff0031ff : i2c ff004500-ff004507 : serial ff004600-ff004607 : serial ff022000-ff022fff : usb ff022000-ff022fff : ehci_hcd ff023000-ff023fff : usb ff023000-ff023fff : usb ff023000-ff023fff : ehci_hcd ff024000-ff024fff : ethernet ff024520-ff02453f : mdio ff025000-ff025fff : ethernet -- 2.6.28 c000-cfff : /p...@ff008500 c000-c3ff : :00:0c.0 c000-c3ff : CoralP_fb c400-c401 : :00:0b.0 c402-c402 : :00:0a.0 c403-c403 : :00:0a.0 c404-c4040fff : :00:0b.0 c404-c4040fff : sata_promise c4041000-c4041fff : :00:0d.0 c4041000-c4041fff : ohci_hcd c4042000-c4042fff : :00:0d.1 c4042000-c4042fff : ohci_hcd c4043000-c40430ff : :00:0d.2 c4043000-c40430ff : ehci_hcd f000-f1ff : f000.flash ff004500-ff004507 : serial ff004600-ff004607 : serial ff022000-ff022fff : usb ff022000-ff022fff : ehci_hcd ff023000-ff023fff : usb ff023000-ff023fff : usb ff023000-ff023fff : ehci_hcd ff024000-ff024fff : ethernet ff024520-ff02453f : mdio ff025000-ff025fff : ethernet I'm still looking into how the PCI address register for the video card did not get written, even though the system obviously thinks it did (hence virtual) It most definitely has something to do with 0xC000 being assigned to the video card. I changed my DTS to move everything up (started the whole space at 0xC400) and the video card came to life! Of course, I'm not interested in this hack, so the simplest thing would be to figure out why 2.6.26 allocated that outgoing window and 2.6.28 doesn't -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
Kumar Gala wrote: On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote: I found the difference - in 2.6.28 the inbound/outbound windows don't seem to be set up at all. In 2.6.26, the function 'fsl_add_bridge' was common among architectures and ended up calling 'setup_pci_atmu' which created those mappings. In 2.6.28, the 83xx PCI setup code has been refactored. It uses 'mpc83xx_add_bridge' instead of 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-( I'm sure this is the problem. Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code calling setup_pci_atmu(). It did not directly; it called 'fsl_add_bridge' which in turn called 'setup_pci_atmu' I modified the 2.6.28 driver to also call this function. Now the inbound/outbound windows are set up, but the bridge still has no allocations, so the problem remains. I need to move on; I may just live with sliding the PCI space up for now (doesn't really hurt anything, just seems like a hack) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] spi_mpc83xx: Handles other Freescale processors
Kumar Gala wrote: On Apr 4, 2009, at 2:28 PM, Anton Vorontsov wrote: With this patch we'll able to select spi_mpc83xx driver on the MPC86xx platforms. Let the driver depend on FSL_SOC, so we don't have to worry about Kconfig anymore. Also remove the experimental dependency, the driver has been tested to work on a various hardware, and surely not experimental anymore. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- drivers/spi/Kconfig | 14 ++ 1 files changed, 6 insertions(+), 8 deletions(-) this looks fine, but why don't we go ahead and rename things as well? SPI_MPC83xx - SPI_MPC8xxx, spi_mpc83xx.c - spi_mpc8xxx.c mpc8xxx implies mpc82xx (e.g. mpc8272) which is not the same controller as on the mpc83xx -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC83xx console : no output after handover
Matthew L. Creech wrote: It turned out that the normally-initialized 8250 driver was getting stomped on by my device tree's serial driver (which is also an 8250) - apparently CONFIG_SERIAL_8250[_CONSOLE] and CONFIG_SERIAL_OF_PLATFORM don't play well together. Disabling the latter fixed my problem. Thanks for the help, and sorry for the noise. Can you share what you had and what you changed it to? I'm running on very similar systems and may face this exact problem soon. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC83xx console : no output after handover
Matthew L. Creech wrote: (Sorry if this is a dupe, but I think my first attempt was filtered out) Nope, it made it. Hi, I'm trying to get Linux booting on a custom board based on the MPC8313 ERDB, but there's no output after the console is transferred. I get the following: Using MPC831x RDB machine description Linux version 2.6.29 (mlcre...@lap) (gcc version 4.3.2 (Sourcery G++ Lite 4.3-50 ) ) #2 PREEMPT Tue Mar 31 14:54:27 EDT 2009 console [udbg0] enabled ... (normal boot output) ... Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A console handover: boot [udbg0] - real [ttyS0] serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A If I boot with console=udbg0,115200, then it gets much further along before printing turn off boot console udbg0. So presumably the kernel is booting beyond this point, but my console isn't printing any output. I traced from that last line back up the call stack to the end of drivers/serial/8250.c:serial8250_init(), and everything seems okay (it returns 0, and pritnk() still works fine at that point). I'm not sure where to go from there to figure out where the problem lies. Could someone point me in the right direction, or suggest what might cause a console problem like this? What does your command line (boot args) when it fails? It should probably have something like console=ttyS0,115200 in it. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC83xx console : no output after handover
Matthew L. Creech wrote: On Tue, Mar 31, 2009 at 4:45 PM, Gary Thomas g...@mlbassoc.com wrote: What does your command line (boot args) when it fails? It should probably have something like console=ttyS0,115200 in it. Yes, that's what I'm using. It also seems to be the default if none is supplied. For the sake of completeness, here's a full dump: Using MPC831x RDB machine description Linux version 2.6.29 (mlcre...@lap) (gcc version 4.3.2 (Sourcery G++ Lite 4.3-50 ) ) #3 PREEMPT Tue Mar 31 15:10:02 EDT 2009 console [udbg0] enabled setup_arch: bootmem mpc831x_rdb_setup_arch() arch: exit Zone PFN ranges: DMA 0x - 0x8000 Normal 0x8000 - 0x8000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x8000 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/mtdblock1 init=/bin/sh console=ttyS0,115200 IPIC (128 IRQ sources) at fdffd700 PID hash table entries: 512 (order: 9, 2048 bytes) clocksource: timebase mult[781] shift[22] registered Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 126236k/131072k available (3260k kernel code, 4692k reserved, 136k data, 98k bss, 160k init) SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 66.30 BogoMIPS (lpj=33152) Mount-cache hash table entries: 512 net_namespace: 708 bytes NET: Registered protocol family 16 bio: create slab bio-0 at 0 Freescale Elo / Elo Plus DMA driver NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered NET: Registered protocol family 1 WDT driver for MPC8xxx initialized. mode:reset timeout=65535 (32 seconds) fsl-elo-dma e00082a8.dma: Probe the Freescale DMA driver for fsl,elo-dma control ler at e00082a8... fsl-elo-dma e00082a8.dma: #0 (fsl,elo-dma-channel), irq 71 fsl-elo-dma e00082a8.dma: #1 (fsl,elo-dma-channel), irq 71 fsl-elo-dma e00082a8.dma: #2 (fsl,elo-dma-channel), irq 71 fsl-elo-dma e00082a8.dma: #3 (fsl,elo-dma-channel), irq 71 squashfs: version 4.0 (2009/01/31) Phillip Lougher Registering unionfs 2.5.1 (for 2.6.29-rc2) yaffs Mar 31 2009 02:31:59 Installing. msgmni has been set to 246 alg: No test for stdrng (krng) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered (default) io scheduler cfq registered Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A console handover: boot [udbg0] - real [ttyS0] serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A The fact that you get the ttyS1 line printed is interesting. At this point, the kernel is switching from raw console I/O (only suitable for bring-up messages) to the general serial driver (interrupt driven, etc). I'm curious about what the ttyS1 driver is causing to break... A couple of things you could try: * Disable ttyS1 (take it out of your device tree) * Look at the console log when this happens. Look in your system map for the symbol '__log_buf', e.g. c031ca54 b __log_buf This will get stored at physical location '0x31ca54' and will often contain data that didn't get a chance to print, for example if you have stuck interrupts that prevent the console from working. I'd just run it to this point and then examine the memory - either using a BDI if one is attached, or press RESET (I hope you have one!) and then look using your boot loader (uBoot, RedBoot, ...) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Xilinx cygwin linux cross recommendations ?
David H. Lynch Jr. wrote: I have no experience with ELDK. Have you used it ? Do you like it ? When I started I mostly did a roll my own environment using crosstool. I would have stuck to that except I can not get uclibc and it has not been updated in a long time. Crosstool-ng did not support the ppc last time I looked. Look again - PowerPC is quite well supported by CrossTool-ng Today I use buildroot - mostly just to build a toolchain - I have never been able to get it to do many of the other things it is capable of. I am not particularly fond (serious understatement) of integrated solve all the problems of the world environments, they rarely work, and you must think inside their box. I would be ecstatic with just a cygwin-linux-ppc-uclibc tool chain. Why not just skip the torture (CygWin) and just run a virtual machine on Windows [I assume you _have_ to have Windows]. Both VM-Ware and VirtualBox handle this problem beautifully. Then you have *Linux* for your development environment, not some cobbled set of pieces... Grant Likely wrote: On Thu, Mar 19, 2009 at 5:59 PM, David H. Lynch Jr. dh...@dlasys.net wrote: Does anyone have experience sugestions for building ppc/linux apps or even ppc kernels under windows. I hear rumors that there is a Windows version of ELDK. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200 SPI
I'm trying to use the PSC/SPI driver on my MPC5200 board
'drivers/spi/mpc52xx_psc_spi.c' My kernel is 2.6.28, but
I don't see any changes in this area in the latest ones.
Cribbing from the Lite5200, I put this in my DTS file:
// PSC6 = SPI
s...@2c00 { // PSC6
compatible = fsl,mpc5200-psc-spi;
cell-index = 5;
reg = 0x2c00 0x100;
interrupts = 2 4 0;
interrupt-parent = mpc5200_pic;
};
I added the SPI device I'm working with (I have to write
this driver, so don't go looking for it). This was added
within the s...@2c00 node, much like various I2C devices, etc.
t...@spi {
compatible = maxim,max6629;
};
Sadly, the SPI master driver seems 100% oblivious to this.
I found the call of_register_spi_devices (drivers/of/of_spi.c),
but it is only used by the xilinx SPI master. Also, I didn't
find any slave examples anywhere.
Is this driver (SPI on MPC5200) supposed to work?
If so, what am I missing to get it set up?
If not, what needs to be done to get it there?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
OF device mappings
Still looking for some help... I need to be able to locate
the kernel platform_device which corresponds to an instance
from my OF tree. Basically, I have a [somewhat] unrelated
driver which needs to know these things, so the drivers in
question should not have to be affected.
In particular, I'm working with the net/dsa drivers (Distributed
Switch Architecture) which need access to the network driver as
well as the MII/MDIO bus driver. It doesn't make sense to tie
those drivers back to DSA, but rather let the DSA driver find
its way to them.
I've defined this in by DTS tree:
lan1 {
cell-index = 0x01;
compatible = marvell,m88e609x;
net_dev = fsl-gianfar.0;
mii_bus = fsl-gianfar_mdio.14;
net_devX = eth0;
mii_busX = mii_bus;
};
... two ways to find the same node.
Using 'net_dev' (which I admit is pretty hokey), I can look
up the corresponding platform device, which does work for
the DSA layer. What I want is to be able to get to this
from the 'net_devX' pointer, but I don't seem to be able
to get out of the OF tree and into the actual platform
device tree to find the appropriate instance.
Any pointers?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF device mappings
Grant Likely wrote:
On Sat, Feb 28, 2009 at 10:46 AM, Gary Thomas g...@mlbassoc.com wrote:
Still looking for some help... I need to be able to locate
the kernel platform_device which corresponds to an instance
from my OF tree. Basically, I have a [somewhat] unrelated
driver which needs to know these things, so the drivers in
question should not have to be affected.
In particular, I'm working with the net/dsa drivers (Distributed
Switch Architecture) which need access to the network driver as
well as the MII/MDIO bus driver. It doesn't make sense to tie
those drivers back to DSA, but rather let the DSA driver find
its way to them.
I've defined this in by DTS tree:
lan1 {
cell-index = 0x01;
Side note, why do you have cell-index here? I suspect that you're
using it incorrectly.
Probably - I don't think I need it anyway.
compatible = marvell,m88e609x;
net_dev = fsl-gianfar.0;
mii_bus = fsl-gianfar_mdio.14;
These two lines don't make much sense. They are encoding Linux
internal details with could very well change in the future.
net_devX = eth0;
mii_busX = mii_bus;
This is the right thing to do. This give you the phandle to the relevant
node.
As I suspected.
Once you have a handle to the node, you can iterate through the
of_platform bus devices and look for a node which has a matching node
pointer stored in archdata. That will give you a struct device which
is contained by a struct of_device (note well: this will give you an
of_device, not a platform_device.)
I have code which does this already, but I could not figure out
how to get from the of_device node to the actual platform_device.
for_each_compatible_node(np, NULL, marvell,m88e609x) {
const phandle *ph;
struct device *dev;
struct of_device *of_dev;
ph = of_get_property(np, net_devX, NULL);
if (ph == NULL) {
printk(%s: missing 'net_dev'\n, np-name);
break;
}
of_dev = of_find_device_by_phandle(*ph);
}
How do I find the platform_device which was created when this
particular of_device was instantiated? I made sure that this code
is run late - after all the of_devices have been handled.
I'm working on a set of patches which should make this much easier.
I'll try to remember to CC you when I post them to the list.
Looking forward to your code/ideas
};
... two ways to find the same node.
Using 'net_dev' (which I admit is pretty hokey), I can look
up the corresponding platform device, which does work for
the DSA layer. What I want is to be able to get to this
from the 'net_devX' pointer, but I don't seem to be able
to get out of the OF tree and into the actual platform
device tree to find the appropriate instance.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF device mappings
Grant Likely wrote:
On Sat, Feb 28, 2009 at 11:21 AM, Gary Thomas g...@mlbassoc.com wrote:
Grant Likely wrote:
Once you have a handle to the node, you can iterate through the
of_platform bus devices and look for a node which has a matching node
pointer stored in archdata. That will give you a struct device which
is contained by a struct of_device (note well: this will give you an
of_device, not a platform_device.)
I have code which does this already, but I could not figure out
how to get from the of_device node to the actual platform_device.
You can't. There is no platform_device. There is only the of_device.
The bit that you're missing is that the 'platform bus' isn't being
used at all for these devices. The 'of_platform bus' is used instead.
platform bus and of_platform bus perform essentially the same job,
but the of_platform bus differs in the way it probes drivers.
Specifically, an of_platform_driver can be handed a list of values
that it will match against, and it has a 1:1 relationship with a node
in the device tree.
How do I find the platform_device which was created when this
particular of_device was instantiated? I made sure that this code
is run late - after all the of_devices have been handled.
Again, there is no platform_device. of_device *is* the device that was
created.
But this doesn't work :-( I also don't understand how you
can say there is no platform_device - they are everywhere,
corresponding to actual device instances, as the system
creates them, typically in a driver 'probe' function.
I've tried both ways. If I look up the of_platform node and
then pass the 'dev' structure to the DSA driver, it doesn't work.
If I look up the actual device instance from the platform_bus
and pass that to the driver, it does.
How do I get to the proper 'dev' structure which will make the
DSA driver work?
More details - the DSA driver is expecting to get the 'dev'
structure pointer which was created in the gianfar driver,
static int gfar_probe(struct platform_device *pdev)
namely 'pdev-dev' -- this works.
If I look up the of_platform device like this:
for_each_compatible_node(np, NULL, marvell,m88e609x) {
const phandle *ph;
struct device *dev;
struct of_device *of_dev;
ph = of_get_property(np, net_devX, NULL);
if (ph == NULL) {
printk(%s: missing 'net_dev'\n, np-name);
break;
}
of_dev = of_find_device_by_phandle(*ph);
and pass 'of_dev-dev', the DSA driver fails.
What am I missing and how do I solve this?
I'm not trying to be obstinate; I just need this to work
and I'm trying to make it work in an extensible, play nice
in the OF sandbox way.
Thanks for your help
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OF device mappings
Grant Likely wrote: On Sat, Feb 28, 2009 at 12:18 PM, Gary Thomas g...@mlbassoc.com wrote: Grant Likely wrote: How do I find the platform_device which was created when this particular of_device was instantiated? I made sure that this code is run late - after all the of_devices have been handled. Again, there is no platform_device. of_device *is* the device that was created. But this doesn't work :-( I also don't understand how you can say there is no platform_device - they are everywhere, corresponding to actual device instances, as the system creates them, typically in a driver 'probe' function. No, struct device is everywhere. struct platform_device is a particular container for a struct device, just like struct of_device is another kind of container for struct device. The board setup code (stuff in arch/powerpc/platforms/*) often calls into the of_platform bus to automatically register an of_device for many of the nodes in the device tree. platform_devices are typically explicitly registered by board setup code and has not relationship whatsoever with the of_platform bus. I've tried both ways. If I look up the of_platform node and then pass the 'dev' structure to the DSA driver, it doesn't work. If I look up the actual device instance from the platform_bus and pass that to the driver, it does. How do I get to the proper 'dev' structure which will make the DSA driver work? More details - the DSA driver is expecting to get the 'dev' structure pointer which was created in the gianfar driver, static int gfar_probe(struct platform_device *pdev) namely 'pdev-dev' -- this works. Ah, it becomes clear now. I seen that the gianfar driver has only recently been converted from a platform bus driver to an of_platform bus driver (see git commit b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4). It will be released as part of 2.6.29. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4 So, for the kernel version you're using, the of_find_device_by_phandle() call will never work. It will for 2.6.29 and beyond. Currently, there is code in arch/powerpc/sysdev/fsl_soc.c which creates the platform_device which you're looking for. Look into that code to figure out how to get a pointer to that platform_device. you can probably iterate over the platform bus (hint: look at bus_find_device() and friends) to find it. Glad we're singing from the same score now :-) I'm working from a stock 2.6.28 kernel - upgrading to anything newer is a bit iffy. Is the code you are referring to in the latest 2.6.29-rc? and I should steal from there? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
OF - platform_device
I'm trying to use some drivers which are not yet OF aware
(in particular net/dsa). In order to use these drivers, I
need platform_device pointers for my network any MII bus (PHY).
In the OF world, how do I get to these? I have a MPC834x
based board and somehow I need access to these devices (from
my DTS file):
m...@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 0x24520 0x20;
phy0: ethernet-...@0 {
interrupt-parent = ipic;
interrupts = 17 0x8;
reg = 0x1;
device_type = ethernet-phy;
};
phy1: ethernet-...@1 {
interrupt-parent = ipic;
interrupts = 18 0x8;
reg = 0x2;
device_type = ethernet-phy;
};
};
enet0: ether...@24000 {
cell-index = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 0x24000 0x1000;
local-mac-address = [ 00 08 e5 11 32 33 ];
interrupts = 32 0x8 33 0x8 34 0x8;
interrupt-parent = ipic;
phy-handle = phy0;
linux,network-index = 0;
};
enet1: ether...@25000 {
cell-index = 1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 0x25000 0x1000;
local-mac-address = [ 00 08 e5 11 32 34 ];
interrupts = 35 0x8 36 0x8 37 0x8;
interrupt-parent = ipic;
phy-handle = phy1;
linux,network-index = 1;
};
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC834x PCI problem
] pdc_read_counter: bccrhv[7FFF] bccrlv[7FFF] pdc_read_counter: bccrh [7FFF] bccrl [7FFF] pdc_read_counter: bccrhv[7FFF] bccrlv[7FFF] pdc_detect_pll_input_clock: scr[] pdc_detect_pll_input_clock: start[1073741823] end[1073741823] pdc_detect_pll_input_clock: PLL input clock[0]Hz It's pretty obvious that the PDC driver is having troubles. The system seems happy otherwise: r...@ppc_target:~ lspci -v 00:00.0 Bridge: Unknown device 1957:0085 (rev 11) Flags: bus master, 66MHz, fast devsel, latency 248 Memory at unassigned (64-bit, prefetchable) Memory at unassigned (64-bit, non-prefetchable) Capabilities: [48] #06 [] 00:0b.0 Mass storage controller: Promise Technology, Inc. 20275 (rev 01) (prog-if 85) Subsystem: Promise Technology, Inc. 20275 Flags: bus master, 66MHz, slow devsel, latency 0, IRQ 19 I/O ports at 1000 [size=8] I/O ports at 1008 [size=4] I/O ports at 1010 [size=8] I/O ports at 1018 [size=4] I/O ports at 1020 [size=16] [virtual] Memory at c000 (32-bit, non-prefetchable) [size=16K] Capabilities: [60] Power Management version 1 Any ideas what might be going [wrong] here? I did notice that both RedBoot [my boot environment] and an older kernel (2.6.20) on this board assigned a non-zero offset in the PCI space for this device: Bus: 0, PCI Device: 11, PCI Func: 0 Vendor Id: 0x105A, Device Id: 0x1275, Command: 0x0007, IRQ: 1 BAR[0]0x1001 / probed size 0x / CPU addr 0xb8001000 BAR[1]0x1009 / probed size 0x / CPU addr 0xb8001008 BAR[2]0x1011 / probed size 0x / CPU addr 0xb8001010 BAR[3]0x1019 / probed size 0x / CPU addr 0xb8001018 BAR[4]0x1021 / probed size 0x / CPU addr 0xb8001020 BAR[5]0x0010 / probed size 0x / CPU addr 0xc010 Could this be a possible problem (maybe the device doesn't like it)? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC834x PCI problem
Gary Thomas wrote:
I have two [internal] boards with MPC8347. Both have a PCI
bus, slightly different set of wired peripherals.
On one board, the PCI seems to be working fine. I can talk
to all of my wired devices, plus one in a plugin slot. The
[PCI portion] DTS for this board looks like this:
pci0: p...@ff008500 {
cell-index = 1;
interrupt-map-mask = 0xf800 0x0 0x0 0x7;
interrupt-map =
/* IDSEL 0x0A (External slot) */
0x5000 0x0 0x0 0x1 fpga_ic 0
0x5000 0x0 0x0 0x2 fpga_ic 1
0x5000 0x0 0x0 0x3 fpga_ic 2
0x5000 0x0 0x0 0x4 fpga_ic 3
/* IDSEL 0x0B (Promise SATA) */
0x5800 0x0 0x0 0x1 fpga_ic 5
0x5800 0x0 0x0 0x2 fpga_ic 5
0x5800 0x0 0x0 0x3 fpga_ic 5
0x5800 0x0 0x0 0x4 fpga_ic 5
/* IDSEL 0x0C (Fujitsu Coral-P) */
0x6000 0x0 0x0 0x1 fpga_ic 4
0x6000 0x0 0x0 0x2 fpga_ic 4
0x6000 0x0 0x0 0x3 fpga_ic 4
0x6000 0x0 0x0 0x4 fpga_ic 4
/* IDSEL 0x0D (Philips USB) */
0x6800 0x0 0x0 0x1 fpga_ic 12
0x6800 0x0 0x0 0x2 fpga_ic 12
0x6800 0x0 0x0 0x3 fpga_ic 12
0x6800 0x0 0x0 0x4 fpga_ic 12
/* IDSEL 0x1F (External slot) */
0xF800 0x0 0x0 0x1 fpga_ic 0
0xF800 0x0 0x0 0x2 fpga_ic 1
0xF800 0x0 0x0 0x3 fpga_ic 2
0xF800 0x0 0x0 0x4 fpga_ic 3
;
interrupt-parent = ipic;
interrupts = 0x13 0x8
0x14 0x8;
bus-range = 0 0;
ranges = 0x0200 0x0 0xC000 0xC000 0x0 0x1000
0x0100 0x0 0x 0xB800 0x0 0x0010;
clock-frequency = ;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = 0xff008500 0x100 /* Internal registers */
0xff008300 0x8; /* Config Space registers */
compatible = fsl,mpc8349-pci;
device_type = pci;
};
This board has a Promise SATA controller in slot 11
(drivers/ata/sata_promise.c)
The second board uses a DTS derived from the first. In fact, the
*only* difference is in the PCI layout:
pci0: p...@ff008500 {
cell-index = 1;
interrupt-map-mask = 0xf800 0x0 0x0 0x7;
interrupt-map =
/* IDSEL 0x0B (Promise SATA) */
0x5800 0x0 0x0 0x1 ipic 0x13 8
0x5800 0x0 0x0 0x2 ipic 0x13 8
0x5800 0x0 0x0 0x3 ipic 0x13 8
0x5800 0x0 0x0 0x4 ipic 0x13 8
;
interrupt-parent = ipic;
interrupts = 0x13 0x8;
bus-range = 0 0;
ranges = 0x0200 0x0 0xC000 0xC000 0x0 0x1000
0x0100 0x0 0x 0xB800 0x0 0x0010;
clock-frequency = ;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = 0xff008500 0x100 /* Internal registers */
0xff008300 0x8; /* Config Space registers */
compatible = fsl,mpc8349-pci;
device_type = pci;
};
This board has a slightly different Promise controller
(drivers/ata/pata_pdc2027x.c)
The basic PCI access code in both drivers is the same.
As mentioned, the first board works fine. The second board
falls apart on PCI access. It's obvious that the PDC2027x
driver is having access problems. Here are some clues from
the boot log (PCI related items only):
Found FSL PCI host bridge at 0xff008500. Firmware bus number: 0-0
PCI host bridge /p...@ff008500 (primary) ranges:
MEM 0xc000..0xcfff - 0xc000
IO 0xb800..0xb80f - 0x
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 5 of device :00:0b.0, will remap
bus: 00 index 0 io port: [0x00-0xf]
bus: 00 index 1 mmio: [0xc000-0xcfff]
pdc_detect_pll_input_clock: scr[]
pdc_read_counter: bccrh [7FFF] bccrl [7FFF
Re: MPC5200 VIRQ question
. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 VIRQ question
Benjamin Herrenschmidt wrote:
On Thu, 2008-12-04 at 06:51 -0700, Gary Thomas wrote:
I have a MPC5200 based board which has an FPGA for external
I/O, etc. This FPGA also funnels interrupts from the various
external devices through to the CPU.
I've defined this structure in my DTS:
[EMAIL PROTECTED] {
device_type = board-control;
#address-cells = 1;
#size-cells = 1;
// Note: includes sub-devices like CAN, A/D, etc
reg = 0xf800 0x10;
fpga_ic: [EMAIL PROTECTED] {
device_type = fpga-int-ctlr;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
interrupts = 2 26 3; // IRQ2
BTW, this is wrong! Are the IRQ mappings on the MPC5200 documented
somewhere? I've looked and looked without much joy. Only by
experimentation did I discover that 1 2 3 corresponds to IRQ2.
interrupt-parent = mpc5200_pic;
};
[EMAIL PROTECTED] {
compatible = am,can;
device_type = can;
interrupts = 0 0;
interrupt_parent = fpga_ic;
reg = 0xf801 0x200;
};
};
Of course, there will be more devices and interrupts later on,
this is just the first of many.
Nothing obviously wrong so far other than you should use compatible
properties to identify your devices, including (especially) the fpga
its pic, and maybe use slightly more verbose entries than am,can :-)
Fair enough, but these are 100% internal devices. I'm only using the
OF tree for them as that seems to be the accepted method (IMO, it's
a bit wrong-headed, but that's another discussion...)
Now the questions:
* How do I choose the VIRQ range supported by my FPGA?
You don't. Linux virtual numbers are allocated sparsely and on the fly.
You basically create an irq_host data structure, specifying what kind of
reverse mapping you want (typically in your case I suspect linear since
your HW interrupt space won't be huge), provide the appropriate
callbacks, all I can suggest here is to look at what others do.
I'm interested in this in particular for the MPC5200, but
also for other chips (I have many such board configurations).
* How do I pass this information along to my drivers? I would
think that the interrupts value for the can interface above
would use a [logical] IRQ (an offset from the base VIRQ),
so how does the driver get the actual number (VIRQ+offset)
when probing the tree?
Depends on the driver. But if they use an OF node, they can do
of_irq_parse_and_map() or something like that. It will walk the tree,
find the controller, map it to an irq_host (via the callbacks your
provided), allocate a virq if not done yet, establish a virq-hw mapping
etc... all for you, and return the virq.
This part is still a bit fuzzy. Where/how does my interrupt controller
driver get this VIRQ? Here's how I created my controller:
fpga_can_irq = irq_of_parse_and_map(fpga_ic, 0);
D_printk((%s: fpga_irq = %d\n, __func__, (u32) fpga_can_irq));
if (fpga_can_irq == 0) {
printk(KERN_ERR %s: Can't find FPGA Interrupt Controller IRQ,
__func__);
return -EINVAL;
}
if (request_irq(fpga_can_irq, fpga_irq_cascade, 0, FPGA CAN, 0)) {
printk(KERN_ERR %s: Can't attach to FPGA Interrupt Controller IRQ,
__func__);
return -EINVAL;
}
fpga_irq_host = irq_alloc_host(of_node_get(fpga_node), IRQ_HOST_MAP_LINEAR,
16, fpga_irq_host_ops, -1);
When I try to get the interrupt number for the CAN sub-device,
I always get zero :-(
for_each_compatible_node(np, can, am,can) {
memset(r, 0, sizeof(r));
rc = of_address_to_resource(np, 0, r[0]);
if (rc) {
return rc;
}
rc = of_irq_to_resource(np, 0, r[1]);
if (rc) {
return rc;
}
}
Note: the of_address_to_resource() call works fine, but the
of_irq_to_resource() fails - always returns 0. Any ideas what
I'm doing wrong?
If they are PCI devices, the PCI code does it all for you.
Sadly, 100% home grown, not PCI.
* I know how to define the interrupt controller using irq_alloc_host()
(once I have the VIRQ range) but it's not clear to me where to stick
this initialization when bringing up my platform.
You don't provide a virq range to irq_alloc_host. You provide a type of
reverse mapping (depending on how sparse your HW numbering scheme is)
and for a linear map, how many entries it contains (which is the size of
your -physical- range).
virqs are allocated on the fly.
Once I get the above call to work, I'll have to figure out how
to get at the VIRQ (so my cascade handler can signal the right
interrupt)
n.b. I only ask
Re: Installation on a MPC5200 based custom board
Angelo wrote: Hi all. I saw that someones trying to work on a custom board based on mpc5200. I have: * u-boot 1.2.0 * kernel 2.6.21 * arch=powerpc * custom dts based on lite5200b.dts * USB port (USB2) configured on the Ethernet port Is it necessary to combine Ethernet and usb nodes? However this is the log when a usb-storage is plugged: hub 1-0:1.0: state 7 ports 2 chg evt 0004 ppc-of-ohci f0001000.usb: GetStatus roothub.portstatus [1] = 0x00010101 CSC PPS CCS hub 1-0:1.0: port 2, status 0101, change 0001, 12 Mb/s hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101 ppc-of-ohci f0001000.usb: GetStatus roothub.portstatus [1] = 0x00100103 PRSC PPS PES CCS usb 1-2: new full speed USB device using ppc-of-ohci and address 2 BUG: soft lockup detected on CPU#0! Call Trace: [C7E05A50] [C0007FD8] show_stack+0x3c/0x194 (unreliable) [C7E05A80] [C004A380] softlockup_tick+0xa4/0xd4 [C7E05AA0] [C002B998] run_local_timers+0x18/0x28 [C7E05AB0] [C002B9D8] update_process_times+0x30/0x7c [C7E05AC0] [C003FF3C] tick_sched_timer+0xb0/0x280 [C7E05B20] [C003C538] hrtimer_interrupt+0x214/0x26c [C7E05B80] [C000E744] timer_interrupt+0x88/0x354 [C7E05BF0] [C0011C04] ret_from_except+0x0/0x14 --- Exception: 901 at handle_IRQ_event+0x7c/0x1e8 LR = handle_level_irq+0x90/0x13c [C7E05CB0] [C7F15C00] 0xc7f15c00 (unreliable) [C7E05CD0] [C004C2E0] handle_level_irq+0x90/0x13c [C7E05CE0] [C0006304] do_IRQ+0x98/0xbc [C7E05CF0] [C0011C04] ret_from_except+0x0/0x14 --- Exception: 501 at schedule+0x38/0x64c LR = schedule_timeout+0x68/0xe4 [C7E05DB0] [C01A1650] usb_hcd_submit_urb+0x190/0x8a0 (unreliable) [C7E05E00] [C02389A4] schedule_timeout+0x68/0xe4 [C7E05E40] [C0238378] wait_for_completion_timeout+0x8c/0x138 [C7E05E80] [C01A2B60] usb_start_wait_urb+0x64/0x124 [C7E05EB0] [C01A2E1C] usb_control_msg+0xc4/0xf0 [C7E05EF0] [C019D0D0] hub_port_init+0x424/0x614 [C7E05F40] [C019F42C] hub_thread+0x434/0xe64 [C7E05FC0] [C0037E60] kthread+0xc0/0xfc [C7E05FF0] [C00123F8] original_kernel_thread+0x44/0x60 ppc-of-ohci f0001000.usb: OHCI Unrecoverable Error, disabled ppc-of-ohci f0001000.usb: OHCI controller state ppc-of-ohci f0001000.usb: OHCI 1.0, NO legacy support registers ppc-of-ohci f0001000.usb: control 0x093 HCFS=operational CLE CBSR=3 ppc-of-ohci f0001000.usb: cmdstatus 0x0 SOC=0 ppc-of-ohci f0001000.usb: intrstatus 0x0074 RHSC FNO UE SF ppc-of-ohci f0001000.usb: intrenable 0x801a MIE UE RD WDH ppc-of-ohci f0001000.usb: ed_controlhead 07fcc000 ppc-of-ohci f0001000.usb: ed_controlcurrent fff0 ppc-of-ohci f0001000.usb: hcca frame #ddb6 ppc-of-ohci f0001000.usb: roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2) ppc-of-ohci f0001000.usb: roothub.b PPCM= DR= ppc-of-ohci f0001000.usb: roothub.status 8000 DRWE ppc-of-ohci f0001000.usb: roothub.portstatus [0] 0x0100 PPS ppc-of-ohci f0001000.usb: roothub.portstatus [1] 0x00030100 PESC CSC PPS ppc-of-ohci f0001000.usb: HC died; cleaning up irq 134: nobody cared (try booting with the irqpoll option) Call Trace: [C046FDF0] [C0007FD8] show_stack+0x3c/0x194 (unreliable) [C046FE20] [C004B358] __report_bad_irq+0x34/0xac [C046FE40] [C004B4AC] note_interrupt+0xdc/0x288 [C046FE70] [C004C344] handle_level_irq+0xf4/0x13c [C046FE80] [C0006304] do_IRQ+0x98/0xbc [C046FE90] [C0011C04] ret_from_except+0x0/0x14 --- Exception: 501 at schedule+0x304/0x64c LR = schedule+0x2d8/0x64c [C046FFA0] [C004A2B4] watchdog+0x4c/0x74 [C046FFC0] [C0037E60] kthread+0xc0/0xfc [C046FFF0] [C00123F8] original_kernel_thread+0x44/0x60 handlers: [c01a1008] (usb_hcd_irq+0x0/0x9c) Disabling IRQ #134 usb 1-2: khubd timed out on ep0in len=0/64 hub 1-0:1.0: cannot reset port 2 (err = -19) hub 1-0:1.0: cannot disable port 2 (err = -19) ppc-of-ohci f0001000.usb: leak ed c7fcc000 (#00) state 0 (has tds) hub 1-0:1.0: cannot reset port 2 (err = -19) hub 1-0:1.0: cannot disable port 2 (err = -19) hub 1-0:1.0: cannot reset port 2 (err = -19) hub 1-0:1.0: cannot disable port 2 (err = -19) hub 1-0:1.0: cannot reset port 2 (err = -19) hub 1-0:1.0: cannot disable port 2 (err = -19) hub 1-0:1.0: cannot disable port 2 (err = -19) hub 1-0:1.0: state 0 ports 2 chg evt 0004 Please mail me any idea... Update to the latest kernel (2.6.27+) - there has been lots of work on the MPC5200 in the past three years (that's how old 2.6.21 is!) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200 VIRQ question
I have a MPC5200 based board which has an FPGA for external
I/O, etc. This FPGA also funnels interrupts from the various
external devices through to the CPU.
I've defined this structure in my DTS:
[EMAIL PROTECTED] {
device_type = board-control;
#address-cells = 1;
#size-cells = 1;
// Note: includes sub-devices like CAN, A/D, etc
reg = 0xf800 0x10;
fpga_ic: [EMAIL PROTECTED] {
device_type = fpga-int-ctlr;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
interrupts = 2 26 3; // IRQ2
interrupt-parent = mpc5200_pic;
};
[EMAIL PROTECTED] {
compatible = am,can;
device_type = can;
interrupts = 0 0;
interrupt_parent = fpga_ic;
reg = 0xf801 0x200;
};
};
Of course, there will be more devices and interrupts later on,
this is just the first of many.
Now the questions:
* How do I choose the VIRQ range supported by my FPGA?
I'm interested in this in particular for the MPC5200, but
also for other chips (I have many such board configurations).
* How do I pass this information along to my drivers? I would
think that the interrupts value for the can interface above
would use a [logical] IRQ (an offset from the base VIRQ),
so how does the driver get the actual number (VIRQ+offset)
when probing the tree?
* I know how to define the interrupt controller using irq_alloc_host()
(once I have the VIRQ range) but it's not clear to me where to stick
this initialization when bringing up my platform.
Thanks for any pointers/ideas
n.b. I've read all the arguments about not using device_type
and this will be resolved. At the moment, I'm basing my
code on a slightly older kernel codebase (2.6.26), so those
entries remain.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200B and the CAN interface
Nick wrote: Hi Everyone, I am looking for information on how to use the CAN driver for the MPC5200b. I have built the kernel (2.6.27) with the MPC5200b can bus drivers and I see them being initialized on start up. [ 37.122041] can: controller area network core (rev 20071116 abi 8) [ 37.128687] NET: Registered protocol family 29 [ 37.133379] can: raw protocol (rev 20071116) [ 37.137807] can: broadcast manager protocol (rev 20080415) I'm pretty sure this is just the SocketCAN interface. You still need a hardware driver (and one which is SocketCAN compatible). I don't see such a driver for the MSCAN (the hardware on the MPC5200) in the stock 2.6.27 tree. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hooking an IRQ on a modified mpc8349emitx board
Scott Wood wrote: On Wed, Sep 03, 2008 at 03:55:41PM -0700, Oscar Takeshita wrote: I've been trying to hook an IRQ on a modified mpc8349emitx board without success. The IRQ is hooked physically to IRQ1/GPIO2[13] on the mpc8349e. No other devices are tied to this pin. I'm using uboot 1.2.0 and kernel 2.6.22.19. Do I need to have a dts entry for this interrupt in order to make request_irq() succeed? How can I find the IRQ number? I tried probe_irq_on/off unfortunately it did not work. Would it be MPC83xx_IRQ_EXT1 in arch/powerpc/include/asm/mpc83xx.h ? I'm new doing kernel work. Any hints appreciated. You need to describe the IRQ in a device tree node and use irq_of_parse_and_map(). request_irq() takes virtual IRQ numbers. Maybe we should put together an arch/powerpc FAQ... That would be wonderful :-) This could help many [of us] over these initial speed-bumps. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
More DTS questions
Thanks for the pointer to the DTC/DTS documents. These
help, but I still have many questions and am unsure how
to solve some problems.
Most particularly, I have a number of platforms with
extended interrupts. In these cases, I have an FPGA
which is used as an interrupt controller, multiplexing
a number of external interrupt sources into one [or more]
processor interrupts.
In the past (arch/ppc world), I simple expanded the number
of interrupts on the platform (NUM_IRQ) such that interrupts
0..N were the standard platform interrupts and N+1..M were
provided by my FPGA. The FPGA support had its own interrupt
tables, etc. Simply installing a single IRQ handler for the
composite got me to the FPGA handler which then de-multiplexed
and passed on the interrupt to the handler for the external
device.
I'm a bit lost as to how to describe this in the DTS. For
example, I have a platform with PCI. I can see how to setup
the rest of the PCI stuff (slots, addresses, etc), but I need
to tell it that the interrupt [in this case list corresponding
to INTA..INTD] is handled by this FPGA based interrupt controller.
Looking at some examples in the sources only bring more questions.
Perhaps someone can guide me through this (from the TQM5200):
[EMAIL PROTECTED] {
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
device_type = pci;
compatible = fsl,mpc5200-pci;
reg = 0xfd00 0x100;
interrupt-map-mask = 0xf800 0 0 7;
interrupt-map = 0xc000 0 0 1 mpc5200_pic 0 0 3
0xc000 0 0 2 mpc5200_pic 0 0 3
0xc000 0 0 3 mpc5200_pic 0 0 3
0xc000 0 0 4 mpc5200_pic 0 0 3;
clock-frequency = 0; // From boot loader
interrupts = 2 8 0 2 9 0 2 10 0;
interrupt-parent = mpc5200_pic;
bus-range = 0 0;
ranges = 0x4200 0 0x8000 0x8000 0 0x1000
0x0200 0 0x9000 0x9000 0 0x1000
0x0100 0 0x 0xa000 0 0x0100;
};
The things that truly aren't clear are the various lists.
For example, how does interrupt-map and interrupts describe
how the interrupts are handled? I don't see any reference in
the code to these names (how does a driver get access to such
properties?) I've read the MPC5200 PCI code (where I'd expect
to find some of these answers) without much elucidation.
Forgive such _newbie_ questions, but I'm just a happy arch/ppc
user trying to catch up to an arch/powerpc world :-)
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Initialization order
I'm working with a couple FreeScale platforms and having trouble getting the RTC which is connected via I2C to work. I had this working fine in the old arch/ppc tree, but it's failing in the arch/powerpc world. Here's the problem - the RTC driver gets initialized *before* the I2C bus and as far as I can tell, the RTC 'probe' function never gets executed. I've peppered the device/bus/driver init code with some extra prints to see the flow: *** ds1307_init.548 *** i2c_register_driver.662 *** i2c_register_driver.674 *** i2c_register_driver.682 *** driver_register.228 (rtc-ds1307) - called from c01963cc *** bus_add_driver.657 - bus: 'i2c', driver: 'rtc-ds1307' *** i2c_register_driver.689 i2c /dev entries driver *** i2c_register_driver.662 *** i2c_register_driver.674 *** i2c_register_driver.682 *** driver_register.228 (dev_driver) - called from c01963cc *** bus_add_driver.657 - bus: 'i2c', driver: 'dev_driver' *** i2c_register_driver.689 *** platform_driver_register.456 (fsl-i2c) - called from c02bbc54 *** driver_register.228 (fsl-i2c) - called from c0162f88 *** bus_add_driver.657 - bus: 'platform', driver: 'fsl-i2c' *** fsl_i2c_probe.361 *** fsl_i2c_probe.361 There is a similar print in the 'ds1307_probe()' function, but as you can see, it's never called :-( Can someone explain what drives the order of these init functions? I can see that it's based on the __XXXinit sections, but I don't see why the RTC functions happen before the FSL-I2C ones. From my system map: c02bb738 t rtc_hctosys c02bb87c t rtc_init c02bb918 T rtc_dev_init c02bb97c T rtc_sysfs_init c02bb98c t ds1307_init c02bb9d0 T i2c_register_board_info c02bbaf4 t i2c_init c02bbb80 t i2c_dev_init c02bbc3c t fsl_i2c_init Any ideas how I can affect this ordering? or should it matter and there's something else going on? Thanks for any pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Initialization order
Scott Wood wrote: On Tue, Sep 02, 2008 at 03:28:19PM -0600, Gary Thomas wrote: I'm working with a couple FreeScale platforms and having trouble getting the RTC which is connected via I2C to work. I had this working fine in the old arch/ppc tree, but it's failing in the arch/powerpc world. Make sure the rtc chip is described in the device tree (search existing trees for rtc@ for examples). That did it, thanks :-) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
DTS question
Following on with my RTC problem, I cutpasted this from
the TQM5200 dts file:
[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] {
device_type = rtc;
compatible = dallas,ds1307;
reg = 0x68;
};
};
However, the dts file I started with had this (*mine*):
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,mpc5200-i2c,fsl-i2c;
cell-index = 1;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
};
Notice the different mix of hex (0xNNN) and implied hex values.
This is really confusing to me. Even more so when I added the
RTC snippet cut directly from the TQM5200 file:
[EMAIL PROTECTED] {
device_type = rtc;
compatible = dallas,ds1307;
reg = 0x68;
};
This yielded a syntax error when merged with my platform dts.
When I changed the 'reg=0x68' to 'reg=68', the syntax error
went away it worked perfectly.
What gives? Why is explicit hex sometimes an error and sometimes not?
Is the format of this file documented anywhere (I've not found it)?
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTS question
David Gibson wrote: On Tue, Sep 02, 2008 at 03:56:30PM -0600, Gary Thomas wrote: snip What gives? Why is explicit hex sometimes an error and sometimes not? Because we changed the format at one point. Originally (the dts-v0 format) it was implicitly hex everywhere, which turned out to be a mistake. So we introduced the new dts-v1 format which uses C-style literals. New-style files are marked with a /dts-v1/; token at the top of the file. Gotcha, thanks. Not sure where I picked up the dts-v0 file I based my platform on, but at least now I understand the magic. Is the format of this file documented anywhere (I've not found it)? It's in Documentation/dts-format.txt in the dtc tree. I don't think that's been included in the version of dtc in the kernel tree, though, so you'll need to download the standalone dtc. Where do I find this dtc tree? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200 FEC problems
I'm adding the Analogue Micro Boa (MPC5200/B) platform to the public 2.6.26 tree. Under heavy network load (sometimes even not so heavy!), I get this error: net eth0: FEC_IEVENT_RFIFO_ERROR I've read the thread about how this leads to an incorrect call to the PHY code in the ISR. It's good to know that part of the problem is being worked on. My question is - what exactly does this error imply? Looking at the MPC5200 manual doesn't give much info - just that there was a Rx FIFO error. I'm also perplexed by the fact that I have two slightly different Boa boards (same CPU rev, speed, etc). About the only thing that's different is the SDRAM setup. One board is rock solid while the other gets this error almost immediately. Also, I sometimes get a Tx timeout on this platform (the one that fails as above). net eth0: transmit timed out Note that I don't have any trouble with this platform running RedBoot or eCos, just Linux :-( Here's the basic info on my platform: [EMAIL PROTECTED]:~ cat /proc/cpuinfo processor : 0 cpu : G2_LE clock : 396.00MHz revision: 1.4 (pvr 8082 2014) bogomips: 49.40 timebase: 2475 Ideas? Any help graciously accepted. n.b. I'm not currently subscribed to this list, so please CC me on any replies. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
