Re: how to make a PowerPC executable??
Hi Umesh, On Tuesday 16 December 2008 13:20:57 umesh krishnan wrote: Hi group, I have a little problem out here. I have some codes with me which i have to run on PowerPC based target. I dont have that particular hardware with me. Can anyone suggest a cross-compiler or an emulator, so that i can compile my codes in linux and make a PowerPC executable from here. I tried qemu but it didn't work. It was making a 386 executable rather than a powerpc executable. The cross compiler option 'powerpc-750-unknown-gnu-gcc' was not coming.. Instead it was to build a 386 based executable. I did everything following the Emulation and cross-development for PowerPC page in the link http://www.ibm.com/developerworks/library/pa-emulation.html .. qemu-ppc emulator was installed correctly but the crosstool was the problem. Please help me out. I cant afford a VxWorks (For the workbench or the Tornado compiler). Any way out.. Can i sit on windows and do something? Is there any emulator like that? I'm fairly new to this field. Kindly guide me through.. Building a gcc-based cross toolchain isn't that difficult nowadays. The crosstool scripts (available at http://www.kegel.com/crosstool/) should make your life much easier. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Modules and inserting into kernel
Hi, On Monday 15 September 2008, VenkataKrishna wrote: I installed ELDK kit and I compiled kernel uImage in linux. Now I want to build and compile device driver your target under MPC8260. How can I do this and inserting you module in Linux. To compile the modules just run make modules in the kernel source tree. After copying the modules to the target, load them with insmod or modprobe (read the manpage for both commands). Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 signature.asc Description: This is a digitally signed message part. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: floating point support in the driver.
On Friday 01 August 2008, Misbah khan wrote: Hi all, I have a DSP algorithm which i am running in the application even after enabling the VFP support it is taking a lot of time to get executed hence I want to transform the same into the driver insted of an user application. Can anybody suggest whether doing the same could be a better solution and what could be the chalenges that i have to face by implimenting such floating point support in the driver. Is there a way in the application itself to make it execute faster. Floating-point in the kernel should be avoided. FPU state save/restore operations are costly and are not performed by the kernel when switching from userspace to kernelspace context. You will have to protect floating-point sections with kernel_fpu_begin/kernel_fpu_end which, if I'm not mistaken, disables preemption. That's probably not something you want to do. Why would the same code run faster in kernelspace then userspace ? -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 signature.asc Description: This is a digitally signed message part. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Question on PowerPC's JTAG instruction
Hi John, On Friday 30 May 2008 03:14, John Zhou wrote: Hi, We want to design a tool to speed up our hardware diagnostics via JTAG port. So we have question to ask for your help: 1. How do we access PowerPC's internal GPRs and SPRs etc. via JTAG instruction? We'v gone through IEEE.1149.1. There are no standard JTAG instruction to access CPU's data bus, including internal or external data bus. Do we must need private JTAG instruction to access CPU's internal resource? That's right. if it is, could you share the documents with us? No public documentation is available. You will need to sign an NDA with Freescale (and probably pay ). I had to design a test bench to program the flash memory on our MPC8248-based hardware, and ended up using JTAG to bitbang the bus signals. Programming the processor through JTAG private instructions would have been faster. 2. For 'BSDL' usage, you know, we have many components on one board and much more signals are processed specically. So, how to integrate PowerPC's BSDL with other components' 'BSDL'? Could you give us any hints on it? or any document is also welcome! Your any help is appreciated! Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpspQNYg8rH9.pgp Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help on MPC82XX USB Host controller Development using m82xx-hcd.
Hi Naren, On Wednesday 04 June 2008 12:12, gforgcc wrote: Laurent Pinchart-4 wrote: The cpm2usb project isn't maintained. If possible you should upgrade to a more recent kernel and switch to the powerpc architecture where a new USB driver called fhci is available. The MPC872ADS is supported in recent kernels so switching shouldn't be too difficult. Hi Laurent, i have some basic queries, i have some knowledge on what is UHCI or OHCI, but can you please brief me what is FHCI and some info regarding this ? googling on this dint help me much.. :( FHCI stands for Freescale Host Controller Interface. The term is unofficial and not referenced in the CPM documentation. we are using powerpc architecture with latest kernel 2.6.25.. and trying to implement the USB host controller driver and have similar problems.. The good news is that Anton Vorontsov wrote and posted a FHCI driver for QE-based parts on the linux-ppc mailing list (search the archive for [PATCH] Freescale QUICC Engine USB Host Controller). The driver can be easily modified to work with CPM2-based parts. The bad news is that, from my experience with the CPM2, the controller is almost unusable. It eats around 40% CPU time on my MPC8248 system, and requires software help to generate SOF tokens, which results in bad SOF tokens being sent on the bus. Most USB disks don't seem to care, but all the USB Bluetooth host controllers I've tested crashed. We will be looking for an external USB host controller (or even another CPU) for the next revision of the design. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpll91ZnKhWt.pgp Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: USB Host Controller driver for the MPC8270 processor
Hi Huub, On Thursday 29 May 2008 13:03, Huub Eikens wrote: Hi, I am in need of a USB Host Controller device for the Freescale MPC8270 for the 2.4 linux kernel (ELDK 3.1.1). On internet I found one, but this is only for version 2.6: http://cpm2usb.sourceforge.net/ I have a few options: 1. backport this driver to 2.4.25 kernel. I would like to know if this is feasible or not. I get the feeling that this will take a lot of time. 2. upgrade my kernel to 2.6.x. This is not preferable for me since I depend on sw modules writen by external partners. If I upgrade, I really really need to be sure that this driver is stable and reliable. 3. Use an external USB Host Controller. Can anyone advise me on which controller to choose that runs stable and reliable on the 2.4.25 kernel (ELDK 3.1.1)? I'd go for option 3. The CPM2 USB host controller is definitely not reliable. It relies on software to prepare SOF tokens, and doesn't do much in hardware. After some experimentation with the FHCI driver posted on linux-ppc by Anton Vorontsov I found out that the driver would eat around 40% of my CPU time, and some SOF tokens would be incorrectly sent. The CPM3 (aka QE) shouldn't have the same SOF issue, as it prepares SOF token without any software intervention, but I doubt it would perform much better in term of CPU time. If you can go for an OHCI/UHCI/EHCI based controller that would be much better. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpCDGvdl87Yv.pgp Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: linux powerpc and device trees
Hi Jan,
On Friday 23 May 2008 16:53, - Reyneke wrote:
Hi All,
I am busy with a platform move from the arch/ppc to arch/powerpc tree of the
linux kernel. Being relatively new to device trees, I'm trying to ensure I
have all the steps covered. The platform is very similar to the AMCC Sequioa
(440EPx) and that board has been used as reference for the code changes
required. Kernel version is 2.6.25, using u-boot 1.2.0 (CONFIG_OF_xxx
enabled, debug output on).
My understanding of the whole powerpc branch boot process is as follows:
1. Add platform to arch/powerpc/platforms/4xx
2. Create a .dts in arch/powerpc/boot/dts
3. Setup .config and compile uImage
4. Compile device tree blob using dtc
5. As test, tftp uImage, RootFS, and deviceblob to system memory
6. Use u-boot's bootm command to boot kernel
Every seems OK, until you get to the boot part. The boot hangs:
Verifying Checksum ... OK
Booting using flat device tree at 0x300
## initrd at 0x0240 ... 0x027FEDF7 (len=8383928=0x7FEDB8)
Loading Ramdisk to 0f332000, end 0fb30db8 ... OK
## Transferring control to Linux (at address ) ...
Using various diagnostics like BDI, ft_dump_blob etc I can see that u-boot
does what I expect it to do, and the device tree blob looks valid. Tracing
into the kernel init all looks fine until you hit MMU_init - at this point
it looks like the total memory is calculated as 0. Evaluating the .dts file
the following lines are immediately suspect:
memory {
device_type = memory;
reg = ; /* Filled in by zImage */
};
This is where I am unclear as to how to prepare the device tree. Is step (4)
correct since I'm using uImage? Where is the memory information suppose to
come from? Previously U-boot passes this kind of data to the kernel via
bd_t - how does it work now using device trees?
U-Boot has to fill the device tree. This is done in the ft_board_setup()
function that every board has to implement. Here is what mine looks like (for
an MPC8248).
void ft_board_setup(void *blob, bd_t *bd)
{
DECLARE_GLOBAL_DATA_PTR;
ft_cpu_setup(blob, bd);
fdt_fixup_ethernet(blob, bd);
fdt_fixup_memory(blob, (u64)bd-bi_memstart, (u64)bd-bi_memsize);
do_fixup_by_compat_u32(blob, fsl,cpm-brg, clock-frequency,
gd-brg_clk, 1);
}
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpcLWljR7cCH.pgp
Description: PGP signature
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help on MPC82XX USB Host controller Development using m82xx-hcd.
Hi Amarendra, On Wednesday 26 March 2008 17:11, Amarendra_Reddy wrote: Hi all, We are working on implementation of the USB host controller driver for the MPC8272ADS (eval board). The USB Host controller on MPC8272 chip is neither UHCI nor OHCI compliant. We downloaded the project cpm2usb and the patches created by Mr.Mike Rapoport from http://cpm2usb.sourceforge.net We integrated the 'm82xx-hcd' into the 2.6.10 source with few changes to usb data structures (usb_hcd,usb_device,usb_host_endpoint) and to struct hc_driver. Also updated the function ''tx_err' present in m82xx-hcd.c. The cpm2usb project isn't maintained. If possible you should upgrade to a more recent kernel and switch to the powerpc architecture where a new USB driver called fhci is available. The MPC872ADS is supported in recent kernels so switching shouldn't be too difficult. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpkIgfofX97C.pgp Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: HDLC driver - dev_free_skb_irq causes Segfault
Hi Russ, On Sunday 10 February 2008 03:32, Russell McGuire wrote: All, So I am in the process of debugging my newly established HDLC driver. More or less modeled after a simplified gianfar / ucc_geth idea. However, after loading, etc. and using the following commands - insmod hdlc-8360.ko - sethdlc hdlc0 hdlc-eth - ifconfig hdlc0 up 192.168.1.100 All is well, and I am seeing IDL interrupts. Great. Now I go to ping an address like, ping 192.168.1.101 I can see that I get the start_xmit function, the IRQ from the QE comes back and reports the TXBD as successfully sent. Here is the problem, when I goto free the skb in the tx_handler, I get a 'Unable to Handle Kernel Paging Request for data at address 0x' Even though for the life of me, I can't see any pointers that are at address zero. I'm experiencing a similar problem here with a in-house HDLC driver. The kernel oopses after some time under high HDLC loads. Could you please post a backtrace to see if our problems are related ? How do you free the skb ? Posting code snippet (or even the whole source code) would help. I have checked the pointer value I am passing in, and indeed it is the exact same pointer I am receiving from the original start-xmit call.. Are we supposed to copy the skb? And free it immediately in the start_xmit? Some special way to store the pointer? My understanding is that the skb is supposed to be freed in the TX interrupt handler. I have tried txbd-buf = skb-data; txbd-buf = virt_to_phys(skb-data); etc.. and various other ways to save that I have seen in the gianfar and ucc_geth drivers. You should map the skb data buffer using dma_map_single. Don't forget to unmap it with dma_unmap_single in the TX interrupt handler. My tx_sk_buff** is identical as alloced the same way. Anyone have any ideas? Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgprD0fsVYS1C.pgp Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Firmware Support for USB Hub
On Wednesday 21 November 2007 18:20, Scott Wood wrote: Misbah khan wrote: Hi all, I am using a 8248 processor which has a USB controller and i need to connect a USB Hub to it, iam using Montavista Linux .I need to know that what are the support i need form Montavista or Open source to have an interface with Usb hub. ??? Is there any driver that we need to make if so what type ??? I don't believe a driver currently exists for CPM USB. There's an experimental out-of-tree driver available at http://cpm2usb.sourceforge.net/ The code is outdated and doesn't work, but that's a starting point. If I remember correctly, CPM2 USB host support requires the host to create SOF packets in software. High system loads will probably mess the bus up. A colleague of mines was told by Freescale to use an external USB controller instead of the MPC8248 bundled one. -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgp8AGNf2l3fJ.pgp Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: videobuf
On Tuesday 30 October 2007 16:28, Robert Woodworth wrote: I'm working on building a v4l2 driver for an FPGA module on a Xilinx Virtex4 PPC. Question: Why does the v4l2 videobuf *depend* on PCI? Historical reasons I guess. The videobuf module has been designed for PCI hardware (bttv if I'm not mistaken). Now that other, non-PCI devices would benefit from videobuf, PCI-specific support is being moved to a separate module. Search the video4linux mailing list archive for discussions about videobuf cleanup. You can get the latest source tree at www.linuxtv.org. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpGLLLT0ZvUc.pgp Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
What's the preferred way to export board information to userspace ?
Hi everybody, I need to export some read-only board-specific information (serial number, boot mode jumper configuration, ...) to userspace applications. Could anyone advice me on the preferred way to do that ? I can easily add a quickdirty sysfs/procfs based implementation, but I was wondering if there was some kind of clean and generic way. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8270 Watchdog - early start
Hi Matias, On Thursday 20 September 2007 10:19, Matias Sundman wrote: Hi, I have a custom MPC8270 board running Linux and u-boot. Now, I enabled the watchdog on the 8270 and need to kick it regularly by writing ; 0x556c 0xaa39 To the internal register @ 0x0x1000e. When I am coming out from head.S to start_kernel I was thinking of kicking it a couple times manually before a timer interrupt is inserted which will take care of it until a superdaemon is taking over. I tried to serve the register as follows; *((volatile unsigned int*)(0xf001000e))=0x556c; *((volatile unsigned int*)(0xf001000e))=0xaa39; But it does not take effect. I thought that since u-boot had set up the IMMR to 0xf000' I could directly write to the register as above. Any clues why this does not work? The Software Service Register (SWSR) is 16-bit wide. Unsigned int on the 8270 is 32-bit wide. You must not reference physical addresses directly after the MMU has been turned on. Use ioremap/iounmap to map/unmaap the CPM registers. If you're using ARCH=ppc, you can also use the global CPM mapping cpm2_immr. Use the out_* macros/functions to write to I/O space. out_be16(cpm2_immr-im_siu_conf.siu_82xx.sc_swsr, 0x556c); out_be16(cpm2_immr-im_siu_conf.siu_82xx.sc_swsr, 0xaa39); Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8270 Watchdog - early start - II
On Thursday 20 September 2007 13:11, [EMAIL PROTECTED] wrote: You still shouldn't use direct access with MMU enabled. Use the global CPM mapping and the I/O access macros. I understand, but I need to kick on the WDT before cpm2_immr is initialized dur to timing constraints. You can then probably get away with the BAT mapping. However you should still use the I/O access macro out_be16. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Device tree compiler
Hi everybody, I'm trying to port a MPC8248-based board from ppc to powerpc. While looking for example DTS files I found out that the Linux kernel sources include a few of them in arch/powerpc/boot/dts. However, they don't compile with the latest device-tree compiler available at git://ozlabs.org/srv/projects/dtc/dtc.git. One of the most common error comes from references to the PIC using a node name instead of a linux,phandler value. As most DTS files in the kernel sources fail to compile, I was wondering if there was another DTC I was not aware of, or if those files have actually never been compiled. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
On Sep 13, 2007, at 8:53 AM, Laurent Pinchart wrote: On Wednesday 11 July 2007 15:17, Laurent Pinchart wrote: cpm2_clk_setup() supports setting FCC clocks only, even though the cpm_clk_target enumeration lists SCC clocks. This patch adds SCC clock support. Any chance this patch (and its 2/2 brother) could be committed ? Have you looked at Scott Wood's cleanup patches. They seem to do some of this. Where can I find them ? I checked in git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 and found nothing relevant. Best regard, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Flash Filesystem
Hi Georg, On Friday 07 September 2007 09:34, schardt wrote: Hi i've some problems using the on board flash memory with linux. i added the support for adm/fujittsu flash in kernel config and add the right parameters for the cfi flash device in physical memory. cat /proc/mtd gives me dev:size erasesize name mtd0: 0040 0001 physmap-flash.0 i added /dev/mtd0 c 90 0 and /dev/mtdblock0 b 31 0 how do i add a partition and filesystem fdisk /dev/mtd0 seems me not to be correct :) There are several ways to definie partitions on an MTD device. Make sure you enable the 'MTD partitioning support' option and have a look at 'RedBoot partition table parsing' and 'Command line partition table parsing': Device Drivers * Memory Technology Device (MTD) support [*] MTD partitioning support RedBoot partition table parsing Command line partition table parsing Another option is to hardcode the partition table in the platform data for the physmap driver. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
On Wednesday 11 July 2007 15:17, Laurent Pinchart wrote: cpm2_clk_setup() supports setting FCC clocks only, even though the cpm_clk_target enumeration lists SCC clocks. This patch adds SCC clock support. Any chance this patch (and its 2/2 brother) could be committed ? Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Flash on ep8248e standard motherboards
Hi Alan,
On Tuesday 04 September 2007 20:08, Alan Bennett wrote:
Please accept my apologies for sending the last email and accept this
email address and question. without the disclaimer.
---
Hello;
We have a custom board based on the ep8248e design from Embedded
Planet and I'm trying to use something other than codewarrior to flash
u-boot srec's
I'm not sure where the problem is, but I'm unable to flash the
u-boot.srec onto the Embedded Planet board (using the BDI2000), let
alone our custom board.
1. Embedded Planet ep8248E
64 MB SDRAM
64 MB Flash (x2 Am29LV256M)
2. Custom
128 MB SDRAM
128 MB Flash (X2 Spansion S29GL512N)
NOTE: CW successfully flashes both parts, but then again, it's CW.
BDI 2000 Config File:
; initialize - FLASH BR0 OR0 (64 Mbyte)
;***
WM320xf0010100 0xfc001801
WM32 0xf0010104 0xfc0008c2
[FLASH]
CHIPTYPEMIRRORX16
CHIPSIZE0x200
BUSWIDTH16
I then attempt to unlock/erase/program
Check for Sanity (NOTE: using BDI 2000 PROMPT)
md 0xf0010100 2
f0010100 : 0xf8001801 - 134211583
f0010104 : 0xf80008b2 - 134215502
md 0xfff0 2
fff0 : 0x10101010269488144
fff4 : 0x10101010269488144
All looks good. (10101010 is the existing planet core header)
TRY TO UNLOCK
unlock 0xfff0 1000
Unlocking flash at 0xfff0
# Invalid parameter for flash programming
TRY TO ERASE
erase 0xfff0 UNLOCK 1000
Erasing flash at 0xfff0
# Erasing flash memory failed
BUT
erase 0x UNLOCK 1000
Erasing flash at 0x
Erasing flash passed
HOWEVER
mm 0x 0xdeadbeef
md 0x 1
: 0x
SO it doesn't seem to allow write access afterall...
You need to use the 'prog' command to write to flash. 'md' won't do.
Is there anyone that has a BDI 2000 config file for flashing the
ep8248e motherboard the 8MB Flash Version (64 MB flash version)
Regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: basic and stupid question on wait_event and wake_up
On Monday 13 August 2007 11:22, Ming Liu wrote: Dear Momen, OK. I see now. So you mean condition is only to judge whether a sleeping process could be waken up or not when wake_up() is executed in other processes or interrupt handlers. What really wakes the process up is still the function of wake_up, right? We just execute wake_up() and then check if condition is true. If yes, the process will leave its sleeping and wake up; if not, it keep sleeping. Am I right? Actually, the process will wake up every time you call wake_up(). It will then evaluate the condition. If the condition is true, the process will return from wait_event. If the condition is false, it will go back to sleep. Best regards, Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: WDT with 82xx
On Monday 16 July 2007 13:15, Matvejchikov Ilya wrote: Hi all! Does anybody use watchdog timer with mpc82xx? I do. -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [POWERPC] Move generic MPC82xx functions out of ADS-specific
Hi Scott, On Wednesday 11 July 2007 17:25, Scott Wood wrote: Laurent Pinchart wrote: On Tuesday 10 July 2007 20:05, Scott Wood wrote: Why are you also moving mpc82xx_ads_show_cpuinfo() to the board file? It's not really ADS-specific; it should just be renamed. For the MPC82xx ADS boards, mpc82xx_ads_show_cpuinfo() prints Vendor : Freescale Semiconductor Machine : PQ2 ADS PowerPC The vendor string is hardcoded to Freescale Semiconductor, and the machine string is defined in pq2ads.h. What should show_cpuinfo() print ? Should the vendor be the board vendor or the CPU vendor ? What about the machine ? Ah, I missed that. I'd just get rid of Vendor altogether, and include the vendor name in the machine name. Is there any standard/documentation regarding what show_cpuinfo should print ? Should it show CPU information only, or board information as well ? What about the memory size, clock settings, ... ? What are the meanings of vendor and machine ? -- Laurent Pinchart CSE Semaphore Belgium ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [POWERPC] Move generic MPC82xx functions out of ADS-specific
Hi Scott, On Wednesday 11 July 2007 17:25, Scott Wood wrote: Laurent Pinchart wrote: On Tuesday 10 July 2007 20:05, Scott Wood wrote: Why are you also moving mpc82xx_ads_show_cpuinfo() to the board file? It's not really ADS-specific; it should just be renamed. For the MPC82xx ADS boards, mpc82xx_ads_show_cpuinfo() prints Vendor : Freescale Semiconductor Machine : PQ2 ADS PowerPC The vendor string is hardcoded to Freescale Semiconductor, and the machine string is defined in pq2ads.h. What should show_cpuinfo() print ? Should the vendor be the board vendor or the CPU vendor ? What about the machine ? Ah, I missed that. I'd just get rid of Vendor altogether, and include the vendor name in the machine name. Is there any standard/documentation regarding what show_cpuinfo should print ? Should it show CPU information only, or board information as well ? What about the memory size, clock settings, ... ? What are the meanings of vendor and machine ? -- Laurent Pinchart CSE Semaphore Belgium ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [POWERPC] Move generic MPC82xx functions out of ADS-specific
Hi Scott, On Wednesday 11 July 2007 17:25, Scott Wood wrote: Laurent Pinchart wrote: On Tuesday 10 July 2007 20:05, Scott Wood wrote: Why are you also moving mpc82xx_ads_show_cpuinfo() to the board file? It's not really ADS-specific; it should just be renamed. For the MPC82xx ADS boards, mpc82xx_ads_show_cpuinfo() prints Vendor : Freescale Semiconductor Machine : PQ2 ADS PowerPC The vendor string is hardcoded to Freescale Semiconductor, and the machine string is defined in pq2ads.h. What should show_cpuinfo() print ? Should the vendor be the board vendor or the CPU vendor ? What about the machine ? Ah, I missed that. I'd just get rid of Vendor altogether, and include the vendor name in the machine name. Is there any standard/documentation regarding what show_cpuinfo should print ? Should it show CPU information only, or board information as well ? What about the memory size, clock settings, ... ? What are the meanings of vendor and machine ? -- Laurent Pinchart CSE Semaphore Belgium ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC82xx ADS SCC ports initialisation
On Tuesday 10 July 2007 20:11, Scott Wood wrote: On Tue, Jul 10, 2007 at 04:19:51PM +0200, Laurent Pinchart wrote: clrbits32(immap-im_cpmux.cmx_scr, (0x0007 (4 - data-clk_tx))); clrbits32(immap-im_cpmux.cmx_scr, (0x0038 (4 - data-clk_rx))); setbits32(immap-im_cpmux.cmx_scr, ((data-clk_tx - 1) (4 - data-clk_tx))); setbits32(immap-im_cpmux.cmx_scr, ((data-clk_rx - 1) (4 - data-clk_rx))); The shift right-hand operand doesn't seem to be correct. Could anyone confirm this ? You are correct; it's broken. That code should be replaced with calls to cpm2_clk_setup (arch/powerpc/sysdev/cpm2_common.c). cpm2_clk_setup currently supports FCC clock setup only, but I've got a patch to add SCC clock setup support. Should I send it ? If my assumption is right, could anyone tell me if the MPC82xx processors are actually supported by the powerpc architecture, or if the MPC82xx ADS code is just a non-functional work in progress. I have a bunch of 8xx/82xx changes pending; I hope to get them cleaned up before the merge window ends. That would be nice. I'll wait for your changes to continue my ppc - powerpc port. I also noticed that U-Boot doesn't have flatten device tree support for the MPC82xx family. No, but cuImage for 82xx is on its way. Ok, nice to know. Adding FDT support to U-Boot for the MPC82xx family will be on my todo-list once I get Linux working with cuImage. Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [POWERPC] Move generic MPC82xx functions out of ADS-specific
On Tuesday 10 July 2007 20:05, Scott Wood wrote: On Tue, Jul 10, 2007 at 01:12:45PM +0200, Laurent Pinchart wrote: The non board-specific mpc82xx_halt and mpc82xx_restart functions are defined in arch/powerpc/platforms/82xx/mpc82xx_ads.c. This patch moves them to mpc82xx.c to make them usable by other MPC82xx boards. Why are you also moving mpc82xx_ads_show_cpuinfo() to the board file? It's not really ADS-specific; it should just be renamed. For the MPC82xx ADS boards, mpc82xx_ads_show_cpuinfo() prints Vendor : Freescale Semiconductor Machine : PQ2 ADS PowerPC The vendor string is hardcoded to Freescale Semiconductor, and the machine string is defined in pq2ads.h. What should show_cpuinfo() print ? Should the vendor be the board vendor or the CPU vendor ? What about the machine ? Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC82xx ADS SCC ports initialisation
Hi Vitaly, On Wednesday 11 July 2007 12:34, Vitaly Bordug wrote: On Wed, 11 Jul 2007 09:11:18 +0200 Laurent Pinchart wrote: On Tuesday 10 July 2007 20:11, Scott Wood wrote: On Tue, Jul 10, 2007 at 04:19:51PM +0200, Laurent Pinchart wrote: clrbits32(immap-im_cpmux.cmx_scr, (0x0007 (4 - data-clk_tx))); clrbits32(immap-im_cpmux.cmx_scr, (0x0038 (4 - data-clk_rx))); setbits32(immap-im_cpmux.cmx_scr, ((data-clk_tx - 1) (4 - data-clk_tx))); setbits32(immap-im_cpmux.cmx_scr, ((data-clk_rx - 1) (4 - data-clk_rx))); The shift right-hand operand doesn't seem to be correct. Could anyone confirm this ? You are correct; it's broken. That code should be replaced with calls to cpm2_clk_setup (arch/powerpc/sysdev/cpm2_common.c). cpm2_clk_setup currently supports FCC clock setup only, but I've got a patch to add SCC clock setup support. Should I send it ? If you have functional approach, please feel free to send it... I haven't been able to test the patch, as I have no ADS hardware to test it on. My MPC82xx board is far from being ported to the powerpc architecture. I'll send the patch anyway. Could you evaluate it ? If my assumption is right, could anyone tell me if the MPC82xx processors are actually supported by the powerpc architecture, or if the MPC82xx ADS code is just a non-functional work in progress. once my last changes were committed, 82xx was supported and worked fine. Pretty long time I had no access to the hardware, hence some minor things might require catch-up. The above code might have been worked by sheer luck though. I have a bunch of 8xx/82xx changes pending; I hope to get them cleaned up before the merge window ends. Since I'm the only person covering 8xx/82xx for a while, I definitely want to look at those changes... That would be nice. I'll wait for your changes to continue my ppc - powerpc port. I also noticed that U-Boot doesn't have flatten device tree support for the MPC82xx family. At the moment, I have a patch to add such a thing, but no ability to validate it still works. If you guys will assist a little, I'll go ahead and submit it to the u-boot list. I'm ready to help, but I'd like to port my board to the powerpc architecture first. FDT support in U-Boot is pretty useless with the ppc architecture. No, but cuImage for 82xx is on its way. Ok, nice to know. Adding FDT support to U-Boot for the MPC82xx family will be on my todo-list once I get Linux working with cuImage. Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
cpm2_clk_setup() supports setting FCC clocks only, even though the
cpm_clk_target enumeration lists SCC clocks. This patch adds SCC clock
support.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
arch/powerpc/sysdev/cpm2_common.c | 38 ++--
1 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2_common.c
b/arch/powerpc/sysdev/cpm2_common.c
index 9244129..459fead 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -138,7 +138,39 @@ int cpm2_clk_setup(enum cpm_clk_target target, int clock,
int mode)
cpmux_t *im_cpmux;
u32 *reg;
u32 mask = 7;
- u8 clk_map [24][3] = {
+ u8 clk_map [][3] = {
+ {CPM_CLK_SCC1, CPM_BRG1, 0},
+ {CPM_CLK_SCC1, CPM_BRG2, 1},
+ {CPM_CLK_SCC1, CPM_BRG3, 2},
+ {CPM_CLK_SCC1, CPM_BRG4, 3},
+ {CPM_CLK_SCC1, CPM_CLK5, 4},
+ {CPM_CLK_SCC1, CPM_CLK6, 5},
+ {CPM_CLK_SCC1, CPM_CLK7, 6},
+ {CPM_CLK_SCC1, CPM_CLK8, 7},
+ {CPM_CLK_SCC2, CPM_BRG1, 0},
+ {CPM_CLK_SCC2, CPM_BRG2, 1},
+ {CPM_CLK_SCC2, CPM_BRG3, 2},
+ {CPM_CLK_SCC2, CPM_BRG4, 3},
+ {CPM_CLK_SCC2, CPM_CLK5, 4},
+ {CPM_CLK_SCC2, CPM_CLK6, 5},
+ {CPM_CLK_SCC2, CPM_CLK7, 6},
+ {CPM_CLK_SCC2, CPM_CLK8, 7},
+ {CPM_CLK_SCC3, CPM_BRG1, 0},
+ {CPM_CLK_SCC3, CPM_BRG2, 1},
+ {CPM_CLK_SCC3, CPM_BRG3, 2},
+ {CPM_CLK_SCC3, CPM_BRG4, 3},
+ {CPM_CLK_SCC3, CPM_CLK5, 4},
+ {CPM_CLK_SCC3, CPM_CLK6, 5},
+ {CPM_CLK_SCC3, CPM_CLK7, 6},
+ {CPM_CLK_SCC3, CPM_CLK8, 7},
+ {CPM_CLK_SCC4, CPM_BRG1, 0},
+ {CPM_CLK_SCC4, CPM_BRG2, 1},
+ {CPM_CLK_SCC4, CPM_BRG3, 2},
+ {CPM_CLK_SCC4, CPM_BRG4, 3},
+ {CPM_CLK_SCC4, CPM_CLK5, 4},
+ {CPM_CLK_SCC4, CPM_CLK6, 5},
+ {CPM_CLK_SCC4, CPM_CLK7, 6},
+ {CPM_CLK_SCC4, CPM_CLK8, 7},
{CPM_CLK_FCC1, CPM_BRG5, 0},
{CPM_CLK_FCC1, CPM_BRG6, 1},
{CPM_CLK_FCC1, CPM_BRG7, 2},
@@ -203,13 +235,13 @@ int cpm2_clk_setup(enum cpm_clk_target target, int
clock, int mode)
if (mode == CPM_CLK_RX)
shift +=3;
- for (i=0; i24; i++) {
+ for (i=0; iARRAY_SIZE(clk_map); i++) {
if (clk_map[i][0] == target clk_map[i][1] == clock) {
bits = clk_map[i][2];
break;
}
}
- if (i == sizeof(clk_map)/3)
+ if (i == ARRAY_SIZE(clk_map))
ret = -EINVAL;
bits = shift;
--
1.5.0
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 2/2] [POWERPC] Use cpm2_clk_setup to configure SCC clocks for the MPC82xx ADS
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] --- arch/powerpc/platforms/82xx/mpc82xx_ads.c | 16 1 files changed, 4 insertions(+), 12 deletions(-) diff --git a/arch/powerpc/platforms/82xx/mpc82xx_ads.c b/arch/powerpc/platforms/82xx/mpc82xx_ads.c index 47cb09f..c8a29b9 100644 --- a/arch/powerpc/platforms/82xx/mpc82xx_ads.c +++ b/arch/powerpc/platforms/82xx/mpc82xx_ads.c @@ -234,12 +234,8 @@ static void init_scc1_uart_ioports(struct fs_uart_platform_info *data) clrbits32(immap-im_ioport.iop_pdird, 0x0001); setbits32(immap-im_ioport.iop_pdird, 0x0002); - clrbits32(immap-im_cpmux.cmx_scr, (0x0007 (4 - data-clk_tx))); - clrbits32(immap-im_cpmux.cmx_scr, (0x0038 (4 - data-clk_rx))); - setbits32(immap-im_cpmux.cmx_scr, - ((data-clk_tx - 1) (4 - data-clk_tx))); - setbits32(immap-im_cpmux.cmx_scr, - ((data-clk_rx - 1) (4 - data-clk_rx))); + cpm2_clk_setup(CPM_CLK_SCC1, data-clk_rx, CPM_CLK_RX); + cpm2_clk_setup(CPM_CLK_SCC1, data-clk_tx, CPM_CLK_TX); iounmap(immap); } @@ -253,12 +249,8 @@ static void init_scc4_uart_ioports(struct fs_uart_platform_info *data) clrbits32(immap-im_ioport.iop_pdird, 0x0200); setbits32(immap-im_ioport.iop_pdird, 0x0400); - clrbits32(immap-im_cpmux.cmx_scr, (0x0007 (4 - data-clk_tx))); - clrbits32(immap-im_cpmux.cmx_scr, (0x0038 (4 - data-clk_rx))); - setbits32(immap-im_cpmux.cmx_scr, - ((data-clk_tx - 1) (4 - data-clk_tx))); - setbits32(immap-im_cpmux.cmx_scr, - ((data-clk_rx - 1) (4 - data-clk_rx))); + cpm2_clk_setup(CPM_CLK_SCC4, data-clk_rx, CPM_CLK_RX); + cpm2_clk_setup(CPM_CLK_SCC4, data-clk_tx, CPM_CLK_TX); iounmap(immap); } -- 1.5.0 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PageFault when I write in the Serial registers, MMU ?
Hi Nicolas, On Wednesday 11 July 2007 17:39, Nicolas Mederle wrote: Hi, I am porting linux on a custom board equipped with a PPC750, and I will like to have some advices on the MMU. I used the powerpc arch, and I built my device tree. I will like to know in which files we can configure the authorizations access for the I/O registers. When I use the function md_ppc.progress, I have a data access fault. I modified the head. S files, for add the BAT config. But I think that it is not correct, and that it is possible to do it elsewhere (platform_init?). Moreover the kernel modify the MMU config, it removes the BATs, and configures the Registers Segments. So, must I remake the configuration? Or is it possible to indicate, at the beginning, which space is reserved for I/O? I studied several patch (sandpoint, PrPMC2800) but none configures really the MMU for I/O registers. In the same way, I read several books, but I am not able to have information that I seek, therefore I am really blocked. I warmly thank you for the assistance which you will be able to bring to me. Mapping : 0x - 0x0FFF : RAM 0x2000 - 0x201F : ASIC ( UART, DMA, GPIO, PIC...) 0x8000 - 0x8FFF : PCI 0xF000 - 0x : Flash The kernel is load at 0x0, an the system is a Run In Memory. Currently, I don't use the flash. You should ioremap() the memory you want to access, and use the I/O access functions defined in asm/io.h. Don't forget to iounmap() once you're done. Best regards, Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [POWERPC] Move generic MPC82xx functions out of ADS-specific
The non board-specific mpc82xx_halt and mpc82xx_restart functions are defined
in arch/powerpc/platforms/82xx/mpc82xx_ads.c. This patch moves them to
mpc82xx.c to make them usable by other MPC82xx boards.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
arch/powerpc/platforms/82xx/mpc82xx.c | 33
+++--
arch/powerpc/platforms/82xx/mpc82xx.h | 24 +
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 31 ++-
arch/powerpc/platforms/82xx/pq2ads.h |1 -
4 files changed, 57 insertions(+), 32 deletions(-)
create mode 100644 arch/powerpc/platforms/82xx/mpc82xx.h
diff --git a/arch/powerpc/platforms/82xx/mpc82xx.c
b/arch/powerpc/platforms/82xx/mpc82xx.c
index cc9900d..d67c754 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx.c
@@ -50,7 +50,7 @@
#include sysdev/fsl_soc.h
#include sysdev/cpm2_pic.h
-#include pq2ads.h
+#include mpc82xx.h
static int __init get_freq(char *name, unsigned long *val)
{
@@ -88,23 +88,24 @@ void __init m82xx_calibrate_decr(void)
(not found)\n);
}
-void mpc82xx_ads_show_cpuinfo(struct seq_file *m)
+#define RMR_CSRE 0x0001
+void m82xx_restart(char *cmd)
{
- uint pvid, svid, phid1;
- uint memsize = total_memory;
+ __volatile__ unsigned char dummy;
- pvid = mfspr(SPRN_PVR);
- svid = mfspr(SPRN_SVR);
+ local_irq_disable();
+ ((cpm2_map_t *) cpm2_immr)-im_clkrst.car_rmr |= RMR_CSRE;
- seq_printf(m, Vendor\t\t: Freescale Semiconductor\n);
- seq_printf(m, Machine\t\t: %s\n, CPUINFO_MACHINE);
- seq_printf(m, PVR\t\t: 0x%x\n, pvid);
- seq_printf(m, SVR\t\t: 0x%x\n, svid);
-
- /* Display cpu Pll setting */
- phid1 = mfspr(SPRN_HID1);
- seq_printf(m, PLL setting\t: 0x%x\n, ((phid1 24) 0x3f));
+ /* Clear the ME,EE,IR DR bits in MSR to cause checkstop */
+ mtmsr(mfmsr() ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
+ dummy = ((cpm2_map_t *) cpm2_immr)-im_clkrst.res[0];
+ printk(Restart failed\n);
+ while (1) ;
+}
- /* Display the amount of memory */
- seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
+void m82xx_halt(void)
+{
+ local_irq_disable();
+ while (1) ;
}
+
diff --git a/arch/powerpc/platforms/82xx/mpc82xx.h
b/arch/powerpc/platforms/82xx/mpc82xx.h
new file mode 100644
index 000..427925b
--- /dev/null
+++ b/arch/powerpc/platforms/82xx/mpc82xx.h
@@ -0,0 +1,24 @@
+/*
+ * MPC82xx setup and early boot code plus other random bits.
+ *
+ * Author: Vitaly Bordug [EMAIL PROTECTED]
+ *
+ * Copyright (c) 2006 MontaVista Software, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef __MACH_MPC82XX_H__
+#define __MACH_MPC82XX_H__
+
+#include linux/init.h
+
+extern void __init m82xx_calibrate_decr(void);
+extern void m82xx_restart(char *cmd);
+extern void m82xx_halt(void);
+
+#endif
+
diff --git a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
index 47cb09f..1af9449 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
@@ -51,6 +51,7 @@
#include sysdev/fsl_soc.h
#include ../sysdev/cpm2_pic.h
+#include mpc82xx.h
#include pq2ads.h
#ifdef CONFIG_PCI
@@ -611,25 +612,25 @@ static int __init mpc82xx_ads_probe(void)
return 1;
}
-#define RMR_CSRE 0x0001
-static void m82xx_restart(char *cmd)
+void mpc82xx_ads_show_cpuinfo(struct seq_file *m)
{
- __volatile__ unsigned char dummy;
+ uint pvid, svid, phid1;
+ uint memsize = total_memory;
- local_irq_disable();
- ((cpm2_map_t *) cpm2_immr)-im_clkrst.car_rmr |= RMR_CSRE;
+ pvid = mfspr(SPRN_PVR);
+ svid = mfspr(SPRN_SVR);
- /* Clear the ME,EE,IR DR bits in MSR to cause checkstop */
- mtmsr(mfmsr() ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
- dummy = ((cpm2_map_t *) cpm2_immr)-im_clkrst.res[0];
- printk(Restart failed\n);
- while (1) ;
-}
+ seq_printf(m, Vendor\t\t: Freescale Semiconductor\n);
+ seq_printf(m, Machine\t\t: %s\n, CPUINFO_MACHINE);
+ seq_printf(m, PVR\t\t: 0x%x\n, pvid);
+ seq_printf(m, SVR\t\t: 0x%x\n, svid);
-static void m82xx_halt(void)
-{
- local_irq_disable();
- while (1) ;
+ /* Display cpu Pll setting */
+ phid1 = mfspr(SPRN_HID1);
+ seq_printf(m, PLL setting\t: 0x%x\n, ((phid1 24) 0x3f));
+
+ /* Display the amount of memory */
+ seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
define_machine(mpc82xx_ads)
diff --git a/arch/powerpc/platforms/82xx/pq2ads.h
b/arch/powerpc/platforms/82xx/pq2ads.h
index 5b5cca6..5056fe5
MPC82xx ADS SCC ports initialisation
Hi everybody, while checking the availability of MPC8260 support in ARCH=powerpc, I ran across a possible issue in SCC ports initialisation for the MPC82xx ADS boards. init_scc1_uart_ioports and init_scc4_uart_ioports in arch/powerpc/platforms/mpc82xx/mpx82xx_ads.c use the following code to configure the SCC clocks: clrbits32(immap-im_cpmux.cmx_scr, (0x0007 (4 - data-clk_tx))); clrbits32(immap-im_cpmux.cmx_scr, (0x0038 (4 - data-clk_rx))); setbits32(immap-im_cpmux.cmx_scr, ((data-clk_tx - 1) (4 - data-clk_tx))); setbits32(immap-im_cpmux.cmx_scr, ((data-clk_rx - 1) (4 - data-clk_rx))); The shift right-hand operand doesn't seem to be correct. Could anyone confirm this ? If my assumption is right, could anyone tell me if the MPC82xx processors are actually supported by the powerpc architecture, or if the MPC82xx ADS code is just a non-functional work in progress. I also noticed that U-Boot doesn't have flatten device tree support for the MPC82xx family. There seem to be still a lot of work to do to support the MPC82xx in the powerpc tree, and the effort is much bigger than just porting a board from ppc to powerpc. Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [PPC]: Add linux/pagemap.h to arch/ppc/mm/tlb.c
When compiled without swap support, arch/mm/tlb.c complains about missing function declarations. This patch fixes the warnings. Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] --- arch/ppc/mm/tlb.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/ppc/mm/tlb.c b/arch/ppc/mm/tlb.c index fa29740..4ff260b 100644 --- a/arch/ppc/mm/tlb.c +++ b/arch/ppc/mm/tlb.c @@ -27,6 +27,7 @@ #include linux/mm.h #include linux/init.h #include linux/highmem.h +#include linux/pagemap.h #include asm/tlbflush.h #include asm/tlb.h -- 1.5.0 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Compiling interrupt controller code as a module
Hi Bill, I wrote a kernel driver for a custom bus (using arch/ppc). The hardware has a cascaded interrupt controller wired to one of the CPU interrupts. The interrupt controller IRQ handler calls __do_IRQ() to dispatch interrupts. Everything worked fine until I tried to compile the code as a module because __do_IRQ() is not exported. Is there a way to compile an interrupt controller as a module, or must it be included in the kernel ? Could you just export __do_IRQ()? That's obviously the easiest solution. As __do_IRQ() is not exported by default, and as the function name starts with two underscores, I got the feeling it was somehow meant to be private. I also had a look at the genirq code. It misses a few exports as well (irq_set_chip_and_handler for instance). Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problem cloning Linus' GIT tree!
After a while however, git exits with the following error message: error: Couldn't get http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/r efs/tags/v2.6.11 for tags/v2.6.11 The requested URL returned error: 404 error: Could not interpret tags/v2.6.11 as something to pull rm: cannot remove directory `/cygdrive/c/home/git/linux-2.6/.git/clone-tmp': Directory not empty Try upgrading git to the last version. I'm already using the latest version (1.5.1) of git but the error still persists. A http 404 error usually reports that something is missing on the server. In fact, if I copy the URL above to web browser, the same error occurs. I had the same issue some time ago. Git used to store tags in the .git/tags directory. Linus repository has somehow been 'stripped' from those tags, which are now stored in the git objects (I'm not sure if the repository has been stripped on purpose, or if the .git/tags directory is just deprecated). I thought upgrading to a newer git release had fixed the problem, but after checking it turns out I had to switch to git:// as well. The http:// protocol might not support stripped repositories. Question: Do git://git.kernel.org and http://www.kernel.org -- Note the *www*(!) physically access the same repository? Or is the http server maybe just a mirror of the git server (which could mean that the two could be out of sync) I'm not sure about that. The http repository is not broken, it's just stripped. The http:// protocol handler in git might need to be fixed. If all fails I could harass our company's network admins to open the git port in the firewall :-) but I'd prefer to fetch the tree via http. Any advice? Is there anyone else who is using Linus' tree via http? You could ask on the git mailing list or IRC channel. Best regards, Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: New driver model in 2.6
Hi,
Anyone knows how, where, when the match device of spi_bus_type structure
is called? I put a printk in spi_match_device function and registered an
spi device in this way:
static struct spi_board_info spi_board_info[] __initdata = {
{
.modalias = m25p80,
.max_speed_hz = 1600,
.bus_num= 0,
.chip_select= 0,
},
};
static int board_init_spi(void)
{
printk(%s\n, __FUNCTION__);
spi_register_board_info(spi_board_info,
ARRAY_SIZE(spi_board_info));
return 0;
}
But spi_match_device is not called and consequently the _probe function
of m25p80 driver is never called.
spi_register_board_info() will add the board information structure to
board_list in drivers/spi/spi.c. The list is walked from scan_boardinfo() in
the same file when a SPI master is registered by spi_register_master(). The
first step would be to check if spi_register_master() is called, and if it
fails before calling scan_boardinfo(). Add a few printk's there.
If a master is correctly registered, scan_boardinfo() will call
spi_new_device(), which in turn calls device_register(). That's where the
spi_match_device() function should be called, using the function pointer
stored in proxy-dev.bus.match.
Hope this helps.
Best regards,
Laurent Pinchart
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: New driver model in 2.6
Hi, spi_register_board_info() will add the board information structure to board_list in drivers/spi/spi.c. The list is walked from scan_boardinfo() in the same file when a SPI master is registered by spi_register_master(). The first step would be to check if spi_register_master() is called, and if it fails before calling scan_boardinfo(). Add a few printk's there. If a master is correctly registered, scan_boardinfo() will call spi_new_device(), which in turn calls device_register(). That's where the spi_match_device() function should be called, using the function pointer stored in proxy-dev.bus.match. Thank you for your help, is it possible that calling spi_register_master() before the spi_register_board_info() and before the registration for m25p80 spi device causes the problem? I think it might, but I'm not sure. Try registering the master after registering board information if you can. Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Moving from arch/ppc to arch/powerpc with an MPC8248 (part 1)
Hi everybody, I'm trying to take the big jump and move my (mostly) stable board support from arch/ppc to arch/powerpc. I'm still at a very early stage, but here are already a few questions. arch/ppc defines some 8260 generic handlers in syslib/mpc8260_setup.c for operations such as halt, reset, show_cpuinfo, ... The MPC82xx ADS in arch/powerpc/platforms/82xx redefines those handles as board-specific functions. Should they be made generic to all 82xx boards, or should I copy them to my board-specific file ? If the code should be shared by all 82xx boards, I'll probably end up copying most of the arch/ppc/syslib/mpc8260_setup.c code to arch/powerpc/platforms/82xx/mpc82xx.c. Best regards, Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
heartbeat replacement in arch/powerpc ?
Hi everybody, is there any feature in arch/powerpc similar to the heartbeat callback in arch/ppc ? I need to reset a watchdog timer every 500ms in the early startup code, before the watchdog timer driver takes over. Best regards, Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Best way to define flash partitions for an MPC8248
Hi everybody, I'm running Linux 2.6.20 on an MPC8248 using arch/ppc/. The system flash is divided in 5 partitions, which are currently defined in both U-Boot and in the Linux kernel (hardcoded in platform specific code in arch/ppc/platforms/). This is error prone, as modifying partition information requires a change to the U-Boot environment variables and a recompilation of the Linux kernel. I would like to get rid of partition data in the kernel. I found 3 ways for the Linux kernel to get those data from elsewhere: - command line parsing (using the mtdparts argument) - redboot partition table parsing - OF device tree (drivers/mtd/maps/physmap_of.c) What is the best suited method ? I don't really like the redboot partition table, is I haven't found any way to write it from U-Boot. Do I need to switch to arch/powerpc/ to use the OF device tree ? If so, is it possible today for the MPC8248 processor, or is it still badly supported in arch/powerpc/ ? Last but not least, is it possible to change the OF device tree from U-Boot at runtime to resize partitions ? Best regards, Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: JTAG emulator for MPC8548E (v2)
Hi Eugene, The new unit works *mostly* fine. No debugging issue (not that I use it that much anyway, now that the board boots Linux), but still a flash programming issue. Programming the target parallel NOR flash works in slow JTAG mode, but not in faster mode using the internal workspace. I reported the problem several months ago and still haven't received any solution. Most likely problem isn't in BDI but in your setup. Depending on the particular chip model, to be able use workspace you must have initialized memory first. In fact, I'm pretty sure you haven't configured chip correctly to make workspace usable. I've been using BDI with various PowerPC and MIPS SoCs for many years. It's an excellent tool, you just have to use it correctly. I wish it was that simple. Sorry, but it is. It's a low level tool which requires deep knowledge of the chip. It is probably a target processor configuration issue, as I can use the workspace if a) the target flash has already been programmed with U-Boot b) the BDI-2000 is misconfigured and fails to stop the target processor at startup. I can thus use the workspace when U-Boot initializes the processor. Wow, so you knew it wasn't BDI but a configuration problem from the start. So it all was just a FUD, how low. I don't agree with you there. It is a configuration issue related to the BDI. For all I know, it could be a bug in the BDI that only occurs when initialising given registers in a given sequence. Or it might be an issue with the BDI-2000 unit I got, which might have a hardware problem. I blamed my configuration file first, but even the tech support people haven't been able to locate the issue. All I know is that U-Boot is able to initialise the processor correctly, but the BDI isn't, even when fed with a configuration file that performs the same initialisation sequence as U-Boot. There are two possible causes : either I got the configuration file wrong and forgot a setting, or the BDI fails to perform one of the steps correctly. I had a look at U-Boot code and tried to initialize the processor registers with the same values, without luck. I asked Abatron's French distributor for technical support, and they haven't been able to help me. They made me try lots of different initialization sequences. Several people online sent me their configuration file, and none of them worked for me. So, there must be a configuration problem somewhere, but even Abatron's technical support haven't been able to find it. That's why I complained about their support in my e-mail. In your original e-mail you made it look like BDI has a bug in it, which in fact isn't true. Bad support might be a concern, I agree, but this doesn't make a tool bad, IMHO. I don't know where the bug is, unfortunately. As I stated, the BDI-2000 is a nice tool, which helped me a lot. I just wish I hadn't suffered such a bad technical support experience. That's probably the French distributor's fault, and it seems I have been very unlucky when contacting Abatron directly. Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8272: Edge triggered IRQ
Found solution:
immap-im_intctl.ic_siexr |= (1 (14 - (irq - SIU_INT_IRQ1)));
Makes it trigger on falling edge
Don't forget to set
irq_desc[SIU_INT_IRQ1].status = ~IRQ_LEVEL;
That should be done in the IRQ initialization function referenced by
ppc_md.init_IRQ.
I have pretty simple code that I did a long time ago
irqreturn_t irq_handler(int irq, void *dev_id, struct pt_regs *regs)
{
..
return IRQ_HANDLED;
}
request_irq(irq,
irq_handler,
SA_INTERRUPT,
irq handler,
NULL);
That code runs on MPC8272 and 2.6.18 kernel.
It triggers IRQ on low level (I thought it was falling edge by default).
So, as long as I have input low level I have hundreds of calls. Pretty
much it keeps calling IRQ handling routine.
How do I make it to trigger on falling edge?
Laurent Pinchart
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
fs_enet driver generating bad interrupts on 2.6.19
Hi everybody, I upgraded to 2.6.19 today, and found a strange issue that seems to be related with the fs_enet driver on a MPC8248. The number of bad interrupts, as reported by /proc/interrupts, seems to grown with the number of packets received and sent by the FCC ethernet controllers. ~ # cat /proc/interrupts sleep 500 cat /proc/interrupts CPU0 1:257 CPM2 SIU Level i2c-mpc 2: 1173 CPM2 SIU Level mpc8260_spi 4: 11 CPM2 SIU Level cpm_uart 23: 0 CPM2 SIU Edge TBox cascade 24:155 CPM2 SIU Edge tbox_spi 33:307 CPM2 SIU Level fs_enet-mac 40: 0 CPM2 SIU Level sdfe_sdi 42: 0 CPM2 SIU Level sdfe_sdi 43:622 CPM2 SIU Level sdfe_sci BAD: 1379 The bad interrupt count is incremented when an interrupt can't be assigned to a peripheral, which means cpm2_get_irq() returns -1. I tried printing the SIU interrupt pending and interrupt mask registers when this happens: sipnrh 0xbc12 sipnrl 0x4000 simrh 0x0600 simrl 0x00b0d000 SIPNR_L.1 is the FCC2 interrupt flag. The FCC2 ethernet has no cable plugged in, so the interrupt is masked. SIPNR_H.0 to SIPNR_H.15 are port C interrupts, and are all masked. As you can see, no peripheral should generate an interrupt. Still, do_IRQ() is called, and cpm2_get_irq() reads the SIU interrupt vector register (SIVEC) to find out that it is equal to 0. The bad interrupts counter is then incremented. The number of bad interrupts increases faster when there is outbound network activity (some non relevant information removed from the following output to make it shorter): ~ # while true; do cat /proc/interrupts; ifconfig eth0; sleep 5; done CPU0 33: 2992 CPM2 SIU Level fs_enet-mac BAD: 1523 eth0 Link encap:Ethernet HWaddr 00:06:E1:80:00:03 RX packets:2814 errors:0 dropped:0 overruns:0 frame:0 TX packets:208 errors:0 dropped:0 overruns:0 carrier:0 CPU0 33: 3027 CPM2 SIU Level fs_enet-mac BAD: 1532 eth0 Link encap:Ethernet HWaddr 00:06:E1:80:00:03 RX packets:2841 errors:0 dropped:0 overruns:0 frame:0 TX packets:217 errors:0 dropped:0 overruns:0 carrier:0 CPU0 33: 3045 CPM2 SIU Level fs_enet-mac BAD: 1533 eth0 Link encap:Ethernet HWaddr 00:06:E1:80:00:03 RX packets:2856 errors:0 dropped:0 overruns:0 frame:0 TX packets:218 errors:0 dropped:0 overruns:0 carrier:0 CPU0 33: 3058 CPM2 SIU Level fs_enet-mac BAD: 1534 eth0 Link encap:Ethernet HWaddr 00:06:E1:80:00:03 RX packets:2869 errors:0 dropped:0 overruns:0 frame:0 TX packets:220 errors:0 dropped:0 overruns:0 carrier:0 CPU0 33: 3090 CPM2 SIU Level fs_enet-mac BAD: 1543 eth0 Link encap:Ethernet HWaddr 00:06:E1:80:00:03 RX packets:2892 errors:0 dropped:0 overruns:0 frame:0 TX packets:229 errors:0 dropped:0 overruns:0 carrier:0 CPU0 33: 3131 CPM2 SIU Level fs_enet-mac BAD: 1553 eth0 Link encap:Ethernet HWaddr 00:06:E1:80:00:03 RX packets:2924 errors:0 dropped:0 overruns:0 frame:0 TX packets:238 errors:0 dropped:0 overruns:0 carrier:0 CPU0 33: 3162 CPM2 SIU Level fs_enet-mac BAD: 1562 eth0 Link encap:Ethernet HWaddr 00:06:E1:80:00:03 RX packets:2946 errors:0 dropped:0 overruns:0 frame:0 TX packets:247 errors:0 dropped:0 overruns:0 carrier:0 CPU0 33: 3193 CPM2 SIU Level fs_enet-mac BAD: 1571 eth0 Link encap:Ethernet HWaddr 00:06:E1:80:00:03 RX packets:2968 errors:0 dropped:0 overruns:0 frame:0 TX packets:256 errors:0 dropped:0 overruns:0 carrier:0 The problem wasn't visible with the 2.6.18 kernel. The number of bad interrupts didn't increase with outbound FCC traffic. Has anyone noticed the same problem ? Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CPM_UART: tcdrain() is broken
Hi Dan, There is, however, a problem left. The SCC controllers have a 32- byte FIFO between the buffer descriptors and the wires. cpm_uart_tx_empty() checks if all buffer descriptors have been processed, but doesn't check if the transmit FIFO is actually empty. There is no way to determine if the hardware FIFO is empty. It's buried under the CPM microcode. I was hoping the information would be somewhere in the parameter RAM :-( . I can't figure out how to do so from the datasheet. Does anyone have an idea ? The original versions of the SCC UART driver used to have a timeout based on the maximum depth of this FIFO and baud rate. After the last BD was empty, it would further wait this amount of time. Lots of these little details seem to have been lost over the years of making a better driver :-) That's a solution, but we might wait longer than necessary then. Vitaly, what's your opinion ? We should at least set fifosize to a proper value (see my previous mail). I'll submit a patch after we agree on the need for an additional delay. Cheers, Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CPM_UART: tcdrain() is broken
Hi, There is, however, a problem left. The SCC controllers have a 32- byte FIFO between the buffer descriptors and the wires. cpm_uart_tx_empty() checks if all buffer descriptors have been processed, but doesn't check if the transmit FIFO is actually empty. There is no way to determine if the hardware FIFO is empty. It's buried under the CPM microcode. I was hoping the information would be somewhere in the parameter RAM :-( . I can't figure out how to do so from the datasheet. Does anyone have an idea ? The original versions of the SCC UART driver used to have a timeout based on the maximum depth of this FIFO and baud rate. After the last BD was empty, it would further wait this amount of time. Lots of these little details seem to have been lost over the years of making a better driver :-) That's a solution, but we might wait longer than necessary then. Vitaly, what's your opinion ? We should at least set fifosize to a proper value (see my previous mail). I'll submit a patch after we agree on the need for an additional delay. Well, I also bothered Dan with the same question some time ago, getting the same answer :) I think here we aught to have this delay ported, but under Kconfig option, so that those who are happy with current being, do not suffer from additional delays. There might be another way. Setting TxBD[CR] to 1 will generate the TX interrupt only when the stop bit of the last character in the buffer begins transmission. I still have to find out if it applies to the time when the CPM clears TxBD[R] as well. If so, this would be better than a fixed delay, but it would also prevent buffers from being sent back-to-back (3 bits of idle are sent between consecutive buffers). Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
CPM_UART: tcdrain() is broken
Hi everybody, while working with a CPM UART port (SMC2), I noticed that tcdrain() doesn't actually wait until all the characters hit the wire. After some investigation, I found out that uart_wait_until_sent() (in drivers/serial/serial_core.c) returns immediately because port-fifosize is equal to 0. The following patch improves the situation by setting fifosize and calling uart_update_timeout() when the baud rate is modified. It didn't break might system, but further testing is probably needed. There is, however, a problem left. The SCC controllers have a 32-byte FIFO between the buffer descriptors and the wires. cpm_uart_tx_empty() checks if all buffer descriptors have been processed, but doesn't check if the transmit FIFO is actually empty. I can't figure out how to do so from the datasheet. Does anyone have an idea ? Best regards, Laurent Pinchart diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c index 38719aa..8bb7f2b 100644 --- a/drivers/serial/cpm_uart/cpm_uart_core.c +++ b/drivers/serial/cpm_uart/cpm_uart_core.c @@ -555,6 +555,11 @@ static void cpm_uart_set_termios(struct } /* + * Update the timeout + */ +uart_update_timeout(port, termios-c_cflag, baud); + + /* * Setup hardware (RTS/CTS) flow control */ if (old == NULL || @@ -960,6 +965,7 @@ struct uart_cpm_port cpm_uart_ports[UART .ops = cpm_uart_pops, .iotype = UPIO_MEM, .lock = SPIN_LOCK_UNLOCKED, + .fifosize = TX_BUF_SIZE * TX_NUM_FIFO, }, .flags = FLAG_SMC, .tx_nrfifos = TX_NUM_FIFO, @@ -974,6 +980,7 @@ struct uart_cpm_port cpm_uart_ports[UART .ops = cpm_uart_pops, .iotype = UPIO_MEM, .lock = SPIN_LOCK_UNLOCKED, + .fifosize = TX_BUF_SIZE * TX_NUM_FIFO, }, .flags = FLAG_SMC, .tx_nrfifos = TX_NUM_FIFO, @@ -991,6 +998,7 @@ #endif .ops = cpm_uart_pops, .iotype = UPIO_MEM, .lock = SPIN_LOCK_UNLOCKED, + .fifosize = TX_BUF_SIZE * TX_NUM_FIFO, }, .tx_nrfifos = TX_NUM_FIFO, .tx_fifosize = TX_BUF_SIZE, @@ -1005,6 +1013,7 @@ #endif .ops = cpm_uart_pops, .iotype = UPIO_MEM, .lock = SPIN_LOCK_UNLOCKED, + .fifosize = TX_BUF_SIZE * TX_NUM_FIFO, }, .tx_nrfifos = TX_NUM_FIFO, .tx_fifosize = TX_BUF_SIZE, @@ -1019,6 +1028,7 @@ #endif .ops = cpm_uart_pops, .iotype = UPIO_MEM, .lock = SPIN_LOCK_UNLOCKED, + .fifosize = TX_BUF_SIZE * TX_NUM_FIFO, }, .tx_nrfifos = TX_NUM_FIFO, .tx_fifosize = TX_BUF_SIZE, @@ -1033,6 +1043,7 @@ #endif .ops = cpm_uart_pops, .iotype = UPIO_MEM, .lock = SPIN_LOCK_UNLOCKED, + .fifosize = TX_BUF_SIZE * TX_NUM_FIFO, }, .tx_nrfifos = TX_NUM_FIFO, .tx_fifosize = TX_BUF_SIZE, ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Flash programming using a BDI2000 on a MPC8248 CPU
Hi everybody, I'm having problems using my BDI2000 to program an external flash on a MPC8248 board. I contacted Abatron's technical support (through its French distributor, as nobody at Abatron seems to speak English or French). They haven't been able to provide a solution (they really don't seem to care) after more than a month, so I'm hoping to find some help here. I can't get the BDI2000 to program the flash using the internal workspace (fast algorithm) on a blank flash. What works: - Programming the flash without using the internal workspace (slow, JTAG-only algorithm). - Programming the flash using the internal workspace ONLY WHEN the flash has already been programmed with a valid U-Boot copy, and the breakpoint specified in the BDI2000 configuration file (BOOTADDR) is set to a wrong value. What doesn't work: - Programming the flash using the internal workspace when the flash is empty. - Programming the flash using the internal workspace when the flash has already been programmed with a valid U-Boot copy, and the breakpoint specified in the BDI2000 configuration file (BOOTADDR) is set to the right value. When the reset breakpoints fails (BOOTADDR set to 0x0100 instead of 0xFFF00100 for instance), U-Boot starts to initialize the board before the BDI2000 freezes the CPU. I assume that must be the reason why programming the flash using the internal workspace then works. I tried having a look at the U-Boot startup code, and initializing the same registers in the BDI2000 configuration file, but without success. I probably missed something. Here is my BDI2000 configuration file. The hardware reset configuration word is set to 0x. - [INIT] WREGMSR 0x WM320x00010004 0x2081 ; SYPCR WM320x00010024 0x ; BCR WM320x0001 0x8224 ; SIUMCR WM320x00010c80 0x0001 ; SCCR WM320x000119c4 0x ; RCCR ; Initialize the flash memory controller WM320x00010100 0x40001001 ; BR0 WM320x00010104 0xf8000834 ; OR0 [TARGET] CPUTYPE 8260; the CPU type (603EV,750,8240,8260) JTAGCLOCK 0 ; use 16 MHz JTAG clock BOOTADDR0xFFF00100 BDIMODE AGENT ; the BDI working mode BREAKMODE SOFT; SOFT or HARD VECTOR CATCH ; catch unhandled exceptions DCACHE NOFLUSH ; data cache flushing (FLUSH | NOFLUSH) SIO 2002 115200 [FLASH] CHIPTYPEMIRRORX16 ; Flash type CHIPSIZE0x100 ; The size of one flash chip in bytes BUSWIDTH16 ; The width of the flash memory bus in bits ERASE 0x4000 CHIP FILEu-boot.bin FORMAT BIN ;WORKSPACE 0x8000 [HOST] IP 192.168.2.1 LOADMANUAL ; load code MANUAL or AUTO after reset [REGS] DMM10x FILEbdi2000/reg8272.def - Any help would be greatly appreciated (and would also prove community support is better than Abatron's commercial support ;-) ). Best regards, Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Flash programming using a BDI2000 on a MPC8248 CPU
Hi Adrian, [INIT] WREGMSR 0x WM320x00010004 0x2081 ; SYPCR WM320x00010024 0x ; BCR WM320x0001 0x8224 ; SIUMCR WM320x00010c80 0x0001 ; SCCR WM320x000119c4 0x ; RCCR ; Initialize the flash memory controller WM320x00010100 0x40001001 ; BR0 WM320x00010104 0xf8000834 ; OR0 It looks like your workspace is in RAM, but there's nothing in the setup above to initialise the memory controller banks for your RAM. Check that you can read and write the workspace locations with mm and md from the BDI command line. The workspace is in internal RAM, mapped at address 0x (the hardware reset configuration register is 0x). I tried setting IMMR to 0xf000 and mapping the SDRAM at 0x, without success. The BDI2000 reports successfull flash programming, but the flash is definitely empty. BDIprog 0x4000 u-boot-1.1.4-ucc32.16-0005 BIN Programming u-boot-1.1.4-ucc32.16-0005 , please wait Programming flash passed BDImd 0x4000 4000 : 4010 : 4020 : 4030 : 4040 : 4050 : 4060 : 4070 : 4080 : 4090 : 40a0 : 40b0 : 40c0 : 40d0 : 40e0 : 40f0 : I made sure I can write to the workspace at 0x8000 using mm and md, using both internal RAM (IMMR = 0x) or SDRAM (IMMR = 0xf000). Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Flash programming using a BDI2000 on a MPC8248 CPU
The workspace is in internal RAM, mapped at address 0x (the hardware reset configuration register is 0x). I tried setting IMMR to 0xf000 and mapping the SDRAM at 0x, without success. The BDI2000 reports successfull flash programming, but the flash is definitely empty. I've also had problems with 8260 family flash programming caused by the processor reading the Hard Reset Configuration Word from flash before the BDI takes over. Does your board allow you to change RSTCONF to stop the processor reading the HRCW? Yes it does. The HRCW is set to 0x by deasserting RSTCONF (logic high). All tests were made with RSTCONF high (and thus HRCW equal to 0x). Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] CPM_UART: Fix non-console transmit
After applying your patch, the transmission doesn't take place at all.. just hanging in write... at least it is possible to exit the program. That's strange. No matter how I test the driver it now works perfectly for me with my patches. Ditto. Your patch fixed my problems. I'd like to see a fix (either this one or another one, there are different solutions) pushed upstream soon, as the problem is quite serious. I'm quite amazed nobody had ever reported it before. Did you apply them both? I only applied [PATCH] CPM_UART: Fix non-console transmit However, I cannot see why the length of the transmission would cause any difference. What is you baud rate on SMC2? How about the TX buffer count and TX FIFO size - have you changed them? I suspect that cpm_uart_tx_pump() could disable your TX interrupt when you have all characters queued in separate TX buffers. I'll test this theory tomorrow. You might want to strace your program and post the results here. Also put #define DEBUG in front of cpm_uart_core.c and cpm_uart_cpm2.c and recompile. You'll get a lot of debugging messages after echo 8 /proc/sys/kernel/printk That should give us clues what goes wrong. The output of stty -F /dev/ttyCPM1 -a would also help. Cheers, Laurent Pinchart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] CPM UART: Fix break generation
When generating a break condition on a serial port, the CPM must be told
beforehand how long the break should be. Unfortunately, this information is
not available through the current serial break handling API. This patch works
around the problem by requesting a 32767 characters break followed by a 0
characters break after the requested duration. The CPM will stop the first
break when the second one is requested. This might not work with future CPM
revisions.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
drivers/serial/cpm_uart/cpm_uart_core.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index c29d87d..aa0a284 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -239,14 +239,23 @@ static void cpm_uart_break_ctl(struct ua
{
struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
int line = pinfo - cpm_uart_ports;
+ volatile u16 *brkcr = IS_SMC(pinfo) ? pinfo-smcup-smc_brkcr
+ : pinfo-sccup-scc_brkcr;
pr_debug(CPM uart[%d]:break ctrl, break_state: %d\n, port-line,
break_state);
if (break_state)
+ {
+ *brkcr = 32767;
cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
+ }
else
+ {
+ *brkcr = 0;
+ cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
cpm_line_cr_cmd(line, CPM_CR_RESTART_TX);
+ }
}
/*
--
1.4.GIT
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Did someone have a working SPI Driver for Linux 2.6
Did someone have a working SPI Driver for Linux 2.6 and the MPC82xx from Freescale? I'm working on such a driver. I will try to send a patch in a few days. The driver is being tested on an MMC device, so basic functionalities should be there, but things are far from being finished. Laurent Pinchart
*** PROBABLY SPAM *** No Clock on SPI
Hi Fred, I?m writing a Driver for SPI. That is not working now. I have a MPC8260 using Linux 2.6.14 (rheap patch). Did someone else write a driver for SPI on this ?C or an other driver? So I can see what i did wrong? I'm working on an SPI driver for the MPC8248. I'll try to send a patch in a few days. My SPCOM[STR] flag isn?t cleared automatically after one clock cycle. What here going wrong ? ( I know this register is write only) There is also no Clock on my SPICLK. Make sure you programmed the SPMODE register correctly. How I have to allocate the Memory for the BD?s and the buffer for the BD?s? The buffer descriptors should be allocated from CPM DPRAM using cpm_dpalloc(). The buffers can be allocated from any DMA-able memory (all system memory). Is there something special when I allocate Memory for my Parameter Ram? You don't need to allocate memory for the parameter RAM. I declared PROFF_SPI equal to 192 (I2C parameter RAM is at 128) in include/asm-ppc/cpm2.h: #define PROFF_SMC1 (0) #define PROFF_SMC2 (64) #define PROFF_I2C (128) #define PROFF_SPI (192) Don't forget to set CPM_DATAONLY_BASE to 256 instead of 128 in the same file. Then, set *(u16 *)(immap-im_dprambase[PROFF_SPI_BASE]) = PROFF_SPI; in your driver code, and set the SPI pram resource to .name = pram, .start = 0x00c0, .end= 0x00ff, .flags = IORESOURCE_MEM, in arch/ppc/syslib/pq2_devices.c Is something wrong with the 2.6 Kernel so i have to use the 2.4 Kernel ? You should not use 2.4. 2.6 is the way to go. Laurent Pinchart
MPC8260 SCC UART hardware flow control
On Wednesday 19 July 2006 20:37, Wolfgang Denk wrote: In message 200607191718.00328.laurent.pinchart at tbox.biz you wrote: I was wondering if anyone had implemented hardware flow control support in the cpm_uart driver. If not, I would appreciate pointers regarding how to do so. You can probably take our 2.4 kernel code as a starting point. But be aware of the inherent restrictions of the CPM, see http://www.denx.de/wiki/view/DULG/UseSCCUARTWithHardwareHandshake I didn't know the CPM implemented hardware flow control as a DTE only. Thanks for the information. As our hardware connects to DCE devices this shouldn't be a problem. [In the end, you might want to configure the handshake signals as GPIO lines and controll these manually. But then you will have to ask yourself why you are using a CPM...] Laurent Pinchart
MPC8260 SCC UART hardware flow control
Hi Mathieu, Hi everybody, I was wondering if anyone had implemented hardware flow control support in the cpm_uart driver. If not, I would appreciate pointers regarding how to do so. Best regards, Laurent Pinchart I had. PQ2 CPM is a dedicated part which handles this aspect for you via its microcode. This also means you can't play with it the old way and making your own HHS with a CD/DSR :). Back to seriousness, rather this means you needn't adding modem signal handling in cpm_uart driver. So don't define modem_something that's an ancient reliq from the times, I guess, no CPM was put auxillary. So how to tell CPM to cope with HHS ? Simple, you just have to put SCC's Dedicated pins the right way which depends on your board type. Remember you can't do any HHS with SMC. Refer to Dedicated Pins chapter in the litterature [41.4.2]. Also take a look at SCC GSMR register [20.8] and to SCC UART mode PSMR register [21-14] to maybe use protocol specificities. Thanks. When you'll have your kernel ready, you would do probably something like : stty -F $port crtscts $SPEED I suppose I also have to add support for the CRTSCTS flag in set_termios. As Wolfgang said HHS works for DTE-DCE only (roughly but visually you must have plugs opposite gender on both ends), trying DTE-DTE HHS dialog is bound to failure despite time spend on it. I'll disable hardware flow control if I need DTE-DTE communication. Thanks for your help. Laurent Pinchart
cpm_uart_port_map not initialised before serial console setup
Hi everybody, while trying to use SCC1 as a serial console, I found a bug in the cpm_uart driver. The cpm_uart_port_map table is initialised by cpm_uart_count() which is called in cpm_uart_init() at module_init() time. cpm_uart_console_setup(), called at console_initcall() time, accesses cpm_uart_port_map, leading to a crash when using any serial port except SMC1 as the serial console. I attached a very simple patch to fix the problem, but it might be subject to race conditions. Could anyone familiar with the cpm_uart driver have a look at it ? Best regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: cpm_uart.patch Type: text/x-diff Size: 403 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060713/a4ed8093/attachment.patch
SIU_INT_IRQ4 in MPC 8260
I am trying to set up a interrupt handler for SIU_INT_IRQ4.
The target I am using is MPC 8260 , emmbedded planet Evaluation board.
The OS is Embedded Linux .
[snip]
But my_interrupt_handler isn't getting called .
Make sure the CPM IRQ controller is properly configured. Here's the code I
used to configure IRQ5 and IRQ6 in edge sensitive mode. Read the MPC8260
datasheet to check how to set other options. If IRQ4 is multiplexed with
other signals, make sure you configured the MPC8260 to use the external pin
as IRQ4.
static void __init tbox_cp11_init_irq(void)
{
volatile intctl_cpm2_t *ic = cpm2_immr-im_intctl;
init_irq();
/* Make IRQ5 and IRQ6 edge sensitive */
ic-ic_siexr |= 1 (14 - (SIU_INT_IRQ5 - SIU_INT_IRQ1));
irq_desc[SIU_INT_IRQ5].status = ~IRQ_LEVEL;
ic-ic_siexr |= 1 (14 - (SIU_INT_IRQ6 - SIU_INT_IRQ1));
irq_desc[SIU_INT_IRQ6].status = ~IRQ_LEVEL;
}
void __init m82xx_board_init(void)
{
init_irq = ppc_md.init_IRQ;
ppc_md.init_IRQ = tbox_cp11_init_irq;
}
Laurent Pinchart
entry point of kernel in RAM at 0x0c--linux tree file name
Hi Arun, please keep the list posted when you reply. Thanks for the response .I would also like to ask another query hoever naive it might sound .I am using a Linux 2.4.1 That's very old. Can't you upgrade to 2.6 ? wherein my entry point code at 0x0c expects at R3 ,R4,R5,R6 some parameters which I strongly suspect to be residual record bi_rec *,start of initrd and end of initrd sections as my kernel is crashing immediately after MMU_init and I suspect that machine _init that is done prior to MMU_init expects __res in R3 as a input parameter .Please confirm . Depending on your platform and boot loader, r3 to r7 are initialized with different values. If you're using ppcboot, the kernel expects r3 to be initialized with the residual record, right. I am using ppcboot2..0.0 as my bootloader . That' very old too. You should upgrade to U-Boot. Also I would like to know how can i enable serial console in these early kernel initialsaiotns process. I am using a CONFIG_SANDPOINT(8260) on a MPC 8245 platform and trying to port the code on MPC8245 platform .the board has a very similar config as a SANDPOINT board . If I'm not mistaken, you can't enable a serial console that early. Do you have a hardware debugger (BDI2000) ? If not, you could try LED debugging. Best regards, Laurent Pinchart
entry point of kernel in RAM at 0x0c--linux tree file name
Hi Arun, I would like to kow what is the entry point to kernel at 0x000 after decompressing and passing control to 0x0c . My kernel crashes somewhere after uncomressing and jumping to 0x0c . If any one can help the .c /.S file that contains the source of kernel startup code in RAM at 0x0/0x0c . The entry point is in arch/ppc/kernel/head.S. Symbols _start and __start are located at 0x and 0x000c respectively. Best regards, Laurent Pinchart
Adding an external interrupt controller
Hi everybody, I'm trying to write a driver for a custom extension bus mapped in my MPC8248 memory space. The bus has 32 interrupt lines which are handled by an interrupt controller connected to a single external interrupt on the MPC8248. I've had a look at the Linux interrupt management code, but haven't found any easy API to add an external interrupt controller. Could someone give me a few pointers regarding how to proceed ? I would like to register the interrupt controller with the interrupt management core, so that request_irq()/free_irq() could be used with the extra interrupts. Thanks in advance for your help. Best regards, Laurent Pinchart PS: If this is not architecture-specific and should be asked on the linux-kernel mailing list, please let me know.
Adding an external interrupt controller
Hi, I'm trying to write a driver for a custom extension bus mapped in my MPC8248 memory space. The bus has 32 interrupt lines which are handled by an interrupt controller connected to a single external interrupt on the MPC8248. I've had a look at the Linux interrupt management code, but haven't found any easy API to add an external interrupt controller. Could No, the linux kernel has this feature. someone give me a few pointers regarding how to proceed ? I would like to register the interrupt controller with the interrupt management core, so that request_irq()/free_irq() could be used with the extra interrupts. Need define the struct hw_interrupt_type your_interrupt_controller and the struct irqaction your_irqaction, and implement member function and hook your interrupt controller to The interrupt controller of MPC8248 with setup_irq. I've had a deeper look at that approach and things are, if not entirely clear, at least clear enough to try coding a simple interrupt controller. There is, though, something that bothers me. My interrupt controller has 32 IRQ lines. If I hook up my interrupt controller using the ppc_md.init_IRQ and ppc_md.get_irq callbacks, only one interrupt will be processed at a time. The interrupt handler acks the interrupt at source, but other interrupts which are already flagged will reinterrupt the CPU as soon as the interrupt handler returns. This is clearly sub-optimal. I noticed that some people call __do_IRQ reintrantly (in arch/ppc/syslib/m82xx_pic.c for instance). Could I do that as well, or is that discouraged ? Any problem regarding the stack size ? Thanks for your help. Best regards, Laurent Pinchart
Binding FCC interfaces to device names in reverse order
Does anyone know why changing the device ids breaks the fs_enet driver ? Obviously, because board-specific platform_data fixup use that id field to detect what soc device is that - fcc1 or fcc2 this case. So the phy's will be wrong-assigned, as well as other stuff. To change order pdevs are registered, you may try to disable all the fccs at the startup, and then enable them after ppc_sys_init, or just shoot enable-disable seq (this was't tested at all, but supposed to work). Enabling the FCCs in a device_initcall() call instead of arch_initcall() works. I had to call ppc_sys_device_fixup manually. Thanks for your help. Laurent Pinchart
Binding FCC interfaces to device names in reverse order
Hello, I'm trying to change the order in which the MPC8248 FCC devices are bound to network interface names. The current behaviour is to handle FCC1, FCC2 and FCC3 in that order. FCC1 is thus mapped to eth0 and FCC2 to eth1 (FCC3 is unused in my design). For some reason I'd like to map FCC2 to eth0 and FCC1 to eth1. Interface names are allocated as devices are registered, so I thought I could change the detection order by modifying the ppc_sys_platform_devices array: ppc_sys_platform_devices[MPC82xx_CPM_FCC1].id = 2; ppc_sys_platform_devices[MPC82xx_CPM_FCC2].id = 1; FCC devices detection is indeed reversed, and FCC2 is mapped to eth0. Plugging a cable into the FCC2 socket prints a message referencing eth0, and ifconfig confirms that eth0 is running. Unfortunately, that's where things stop working. I can't ping FCC1 or FCC2, no data is received by the kernel. Does anyone know why changing the device ids breaks the fs_enet driver ? Laurent Pinchart
MMC/SD driver using SPI interface on MPC8248
Hi everybody, I'm looking for an MMC/SD driver using the MPC8248 SPI interface. Does anyone know if such a driver exist, or if some code has already been written ? If no such project exists, could anyone outline the basic architecture of such a driver ? As recent Linux kernels include an SPI class, I suppose I should write a generic MMC/SD-SPI driver which would work with any SPI controller, and write an SPI driver for the MPC8248 (which seem to have a similar interface to the already supported MPC83xx). How should the generic MMC/SD-SPI driver be mapped to specific SPI ports ? Best regards, Laurent Pinchart
CPM_UART should allocate DPRAM for SMCx parameter RAM on MPC82xx
Hi Vitaly, If and when you'll have some code that address your problem, submit it to me cc linuxppc-embedded, and I'll push it upstream. here's a simple patch (against 2.6.17-rc6) that fixes the issue by modifying the pram addresses for SMC resources. I'm not completely satisfied, as the SMCx_BASE registers configuration is board-specific (must be handled in init_ioports as you mentionned in your previous e-mail), which will lead to duplicated code. Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: pq2_devices.diff Type: text/x-diff Size: 1047 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060612/1c397cdb/attachment.diff
CPM_UART should allocate DPRAM for SMCx parameter RAM on MPC82xx
Hi everybody, the move to platform devices introduced a bug in the CPM_UART SMC driver. Unlike SCC and FCC, the SMC parameter ram is not at a fixed location. A pointer to the parameter ram is instead stored at PROFF_SMCx_BASE. The SMC platform device resources (in arch/ppc/syslib/pq2_devices.c) reserves the memory resource PROFF_SMCx_BASE - PROFF_SMCx_BASE+1. The CPM UART driver considers that value as the SMC parameter ram offset. It should instead allocate 64 bytes (on a 64 bytes boundary) of DPRAM for its parameter ram, and store the offset at PROFF_SMCx_BASE. I'm not sure how to fix the problem as it seems that the platform device support is not complete yet (cpm_uart_init_portdesc is still used to initialize the console). A possible workaround is to set the pram resource to 0x-0x003f and 0x0040-0x007f instead of 0x87fc-0x87fd and 0x88fc-0x88fd for SMC1 and SMC2. This will not work if cpm_uart_init_portdesc is not called. Laurent Pinchart
CPM_UART should allocate DPRAM for SMCx parameter RAM on MPC82xx
the move to platform devices introduced a bug in the CPM_UART SMC driver. Unlike SCC and FCC, the SMC parameter ram is not at a fixed location. A pointer to the parameter ram is instead stored at PROFF_SMCx_BASE. The SMC platform device resources (in arch/ppc/syslib/pq2_devices.c) reserves the memory resource PROFF_SMCx_BASE - PROFF_SMCx_BASE+1. The CPM UART driver considers that value as the SMC parameter ram offset. It should instead allocate 64 bytes (on a 64 bytes boundary) of DPRAM for its parameter ram, and store the offset at PROFF_SMCx_BASE. I'm not sure how to fix the problem as it seems that the platform device support is not complete yet (cpm_uart_init_portdesc is still used to initialize the console). A possible workaround is to set the pram resource to 0x-0x003f and 0x0040-0x007f instead of 0x87fc-0x87fd and 0x88fc-0x88fd for SMC1 and SMC2. This will not work if cpm_uart_init_portdesc is not called. No, pdev support for cpm uart is complete and works for every board I have handy, both 8xx and 82xx. 8xx use SMC stuff and are ok, so I suppose the issue got inside because this is first case we head with combination of pq2/smc. init_portedsc is called in compatibility mode only, when driver was unable to locate platform device (early_uart_get_pdev call). The offsets are definitely odd - we should count the proper values (as it was done for 8xx - offset from immr where pram will be located that is). So, pq2_devices should be fixed, as well as bsp code should provide early_uart_get_pdev call (see 8272 as reference).
*** PROBABLY SPAM *** Re: CPM_UART should allocate DPRAM for SMCx parameter RAM on MPC82xx
As I said, SMC offsets relative to pram things are screwed for PQ2. That needs to be fixed. It is assumed, that for each SMC ready-for-use offset should be defined in pram resource (as for 8xx). There is no need to dpalloc/dpfree because the idea is that pram thing should be fixed to prevent confusion. So the odd offset for SMC devices in pq2_devices.c should be replaced with correct values (which should be dpram_start+PROFF_SMCx - have a look at 8xx as reference) Ok. dpram[PROFF_SMCx_BASE] must still be set to the values returned by platform_get_resource_byname(). Where should that be done ? Laurent Pinchart
LXT973 support (dual PHY with single MDIO)
Hi everybody, I'm trying to bring up the two ethernet ports on a LXT973 dual-PHY chip. I've declared two FCC platform devices, which are detected and handled by the driver/net/fs_enet driver. My issue comes from MDIO support. The LXT973 has a single MDIO port which answers to two addresses, one for each PHY. The MDC and MDIO lines are connected to GPIO pins (no PHY interrupt), so I'm using the bitbang MDIO driver. I've declared a MPC82xx_MDIO_BB platform device, and set bus_id to 0:00 for both FCC ethernet devices. The first ethernet device works fine, but the second complains that the PHY is already in use. As the PHY read/write accesses are protected by the bus-mdio_lock, I thought about declaring a second MDIO platform device using the same I/O pins as the first. Does anybody knows any problem I could run into using that approach ? Is there a better method to handle the LXT973 MDIO ? Thanks in advance for any help you can provide. Best regards, Laurent Pinchart
[SOLVED] LXT973 support (dual PHY with single MDIO)
Hi, once again, posting to a mailing list helped me solving my problem. It should have been obvious that the MDIO bus is really a bus, and can as such support several devices. The issue was that the drivers/net/fs_enet driver set bus-phy_mask to ~0x9, and the LXT973 uses addresses 0 and 1. Address 1 thus never got probed. What's the reason for probing addresses 0 and 3 only ? Laurent Pinchart
fs_enet segfaults when adding network interface to bridge
Hi everybody, I ran into a segfault in the fs_enet driver when adding the network interface to an ethernet bridge. This only happens when the interface is down. - Kernel version - Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30 13:25:37 CEST 2006 ppc unknown (from main linux-2.6 git repository) - End of kernel version - - Oops report - Oops: kernel access of bad area, sig: 11 [#1] NIP: C0109884 LR: C010D420 CTR: REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-g7f02f290-dirty) MSR: 9032 EE,ME,IR,DR CR: 24000222 XER: DAR: 0140, DSISR: 2000 TASK = c0851090[42] 'brctl' THREAD: c027c000 GPR00: C010D414 C027D8A0 C0851090 C027D8D0 F0A0 EFFF GPR08: C026E380 C021 C023 C021 1001D150 00FFE000 0001 GPR16: 007FFF00 7FDD0AC0 10072C94 7FDD0AD8 10072CA4 GPR24: 1A48 C027D8D0 C027D8D0 C08A1A60 C027DC50 C08A1800 NIP [C0109884] phy_ethtool_gset+0x0/0x48 LR [C010D420] fs_get_settings+0x34/0x48 Call Trace: [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable) [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8 [C027DC40] [C018CBC0] port_cost+0x58/0x108 [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4 [C027DCE0] [C018D9AC] add_del_if+0x94/0x98 [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4 [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404 [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8 [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220 [C027DEE0] [C0067164] do_ioctl+0x88/0x9c [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0 [C027DF10] [C00675A8] sys_ioctl+0x40/0x74 [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38 Instruction dump: 7c0803a6 4e800020 2f80 409eff78 4bb8 8804000e 2b81 40bdff70 3860ffea 4bd4 61200040 4b84 81230140 91240004 80030144 90040008 - End of oops report - - Source lines - [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290) [C010D414] fs_get_settings+0x28/0x48 (drivers/net/fs_enet/fs_enet-main.c:885) [C013DDC0] dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122) [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54) - End of source lines - phy_ethtool_gset segfaults when trying to access phydev-supported because phydev is NULL. As I'm not familiar with the fs_enet driver, I'm looking for advices regarding what to fix and how to fix it. Laurent Pinchart
fs_enet turns promiscous mode off in restart()
Hi everybody, I'm having an issue with promiscuous mode in the fs_enet driver. The restart() function in drivers/net/fs_enet/mac-fcc.c writes to the FPSMR register: W32(fccp, fcc_fpsmr, FCC_PSMR_ENCRC); This disable promiscuous mode. Shouldn't set_multicast_list() be called at the end of restart() to restore promiscuous (and multicast) settings ? A similar issue exists for the FEC and SCC backends. Laurent Pinchart
fs_enet segfaults when adding network interface to bridge
Hi everybody, I ran into a segfault in the fs_enet driver when adding the network interface to an ethernet bridge. This only happens when the interface is down. - Kernel version - Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30 13:25:37 CEST 2006 ppc unknown (from main linux-2.6 git repository) - End of kernel version - - Oops report - Oops: kernel access of bad area, sig: 11 [#1] NIP: C0109884 LR: C010D420 CTR: REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-g7f02f290-dirty) MSR: 9032 EE,ME,IR,DR CR: 24000222 XER: DAR: 0140, DSISR: 2000 TASK = c0851090[42] 'brctl' THREAD: c027c000 GPR00: C010D414 C027D8A0 C0851090 C027D8D0 F0A0 EFFF GPR08: C026E380 C021 C023 C021 1001D150 00FFE000 0001 GPR16: 007FFF00 7FDD0AC0 10072C94 7FDD0AD8 10072CA4 GPR24: 1A48 C027D8D0 C027D8D0 C08A1A60 C027DC50 C08A1800 NIP [C0109884] phy_ethtool_gset+0x0/0x48 LR [C010D420] fs_get_settings+0x34/0x48 Call Trace: [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable) [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8 [C027DC40] [C018CBC0] port_cost+0x58/0x108 [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4 [C027DCE0] [C018D9AC] add_del_if+0x94/0x98 [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4 [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404 [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8 [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220 [C027DEE0] [C0067164] do_ioctl+0x88/0x9c [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0 [C027DF10] [C00675A8] sys_ioctl+0x40/0x74 [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38 Instruction dump: 7c0803a6 4e800020 2f80 409eff78 4bb8 8804000e 2b81 40bdff70 3860ffea 4bd4 61200040 4b84 81230140 91240004 80030144 90040008 - End of oops report - - Source lines - [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290) [C010D414] fs_get_settings+0x28/0x48 (drivers/net/fs_enet/fs_enet-main.c:885) [C013DDC0] dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122) [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54) - End of source lines - phy_ethtool_gset segfaults when trying to access phydev-supported because phydev is NULL. As I'm not familiar with the fs_enet driver, I'm looking for advices regarding what to fix and how to fix it. IIRC, fs_enet got bound to phydev only being -up. So in down state, phydev may be either null, or last assigned (need to have a look into source to tell for certain). So what is the proper behavior from your point of view? I have no idea :-) What I know is that the driver should not segfault when asked to report the port speed. Either we should return an error or have the phy device bound to fs_enet at all time. It might also be a bridge issue, maybe the bridge code should turn the interface up before reading its speed. How do other ethernet drivers proceed ? Laurent Pinchart
I2C bus issues on MPC8248
Hi Heiko, I'm trying to use the MPC8248 hardware I2C bus in a 2.6.16 kernel. The mailing list archives mention a driver for the MPC8260 (http://ozlabs.org/pipermail/linuxppc-embedded/2006-May/022837.html) which I modified to reflect the memory map differences between the MPC8260 and the MPC8248, as mentionned in the e-mail. The good news is that the driver works. The bad news is that it doesn't work OK. correctly. :-( : The Linux I2C layer probes the I2C bus for peripherals when drivers are loaded. The probing function writes a single byte with the device address and check if the data is acked. I monitored the SCL and SDA lines using an [...] Using that code, no data is sent on the bus, the BD_SC_READY bit is never cleared and no interrupt is generated. Once again I suspected a CPM bug when writing a single byte on the bus, so I increased cbd_datlen to 2: tbdf[0].cbd_bufaddr = __pa(tb); tbdf[0].cbd_datlen = 2; tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START : BD_SC_READY | BD_IIC_START | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP; This worked, and two bytes were written on the bus, leading me to believe that the CPM was at fault. I don t know, if this is a CPM Bug, but it seems so to me ... I've contacted Freescale's technical support about that issue. They answered that 0-byte buffer descriptors are not legal (even though no documentation states so), and that the address byte is output on the I2C bus when the next byte is written to the internal TX FIFO, making it impossible to send a single byte on the bus. Basically, that's a feature, and they don't intend to fix it. Has anyone noticed the same behaviour ? Is there a workaround available ? I tried searching Freescale's website for CPM microcode updates but haven't found anything related to the I2C controller. Yes, Holger Speck had the same problem. He solved it by doing the following: If the cpm_iic_write is called with count = 0. He made a read with count = 1 I think this is safer than writing 2 Bytes to the Slave. Could you try this? I've tried that with success. The I2C bus still gets stuck from time to time, I'll try to investigate that. Thanks for your help. Best regards, Laurent Pinchart
SCC1 as serial console
Hi Ladislav, can anybody help me to setup the SCC1 port as serial console on MPC860 with kernel 2.6.15.4? I would like to use it as system console during the booting proccess. I can not get any output on serial console during booting proccess, I use uboot. Does SCC1 work correctly in U-Boot ? If not, you should fix that first. I'll assume it does. There are many issues which could lead to a silent serial console. The serial port could be misconfigured, or the kernel could crash for another reason before the serial port is initialized. Have you been able to get a serial console on another serial port (SMC) ? Are the clock frequencies computed by U-Boot and passed to the Linux kernel correct ? Do you have a hardware debugger (BDI2000) that you can connect to the processor to see if Linux crashes before initializing the serial port ? If not, you will probably have to take a try at led-debugging (make some leds blink at various point in the Linux kernel to try to find out what happens), but that's really no fun. Laurent Pinchart
I2C bus issues on MPC8248
Hi everybody, I'm trying to use the MPC8248 hardware I2C bus in a 2.6.16 kernel. The mailing list archives mention a driver for the MPC8260 (http://ozlabs.org/pipermail/linuxppc-embedded/2006-May/022837.html) which I modified to reflect the memory map differences between the MPC8260 and the MPC8248, as mentionned in the e-mail. The good news is that the driver works. The bad news is that it doesn't work correctly. The Linux I2C layer probes the I2C bus for peripherals when drivers are loaded. The probing function writes a single byte with the device address and check if the data is acked. I monitored the SCL and SDA lines using an oscilloscope, and found out that 5 bytes are written to the device (address + 4 data bytes) instead of a single one. The first 4 bytes are acked, the last isn't. After further investigation, I found out that the cpm_iic_write() function in drivers/i2c/busses/i2c-mpc8260.c fills two buffer descriptors, the second one having cbd_datlen set to zero: tbdf[0].cbd_bufaddr = __pa(tb); tbdf[0].cbd_datlen = 1; tbdf[0].cbd_sc = BD_SC_READY | BD_IIC_START; tbdf[1].cbd_bufaddr = __pa(buf); tbdf[1].cbd_datlen = count; tbdf[1].cbd_sc = BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP; Still, 5 bytes are sent on the bus. I suspected a CPM bug when cbd_datlen is equal to zero, so I modified the first buffer descriptor to set the BD_SC_LAST in cbd_sc when count is zero: tbdf[0].cbd_bufaddr = __pa(tb); tbdf[0].cbd_datlen = 1; tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START : BD_SC_READY | BD_IIC_START | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP; Using that code, no data is sent on the bus, the BD_SC_READY bit is never cleared and no interrupt is generated. Once again I suspected a CPM bug when writing a single byte on the bus, so I increased cbd_datlen to 2: tbdf[0].cbd_bufaddr = __pa(tb); tbdf[0].cbd_datlen = 2; tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START : BD_SC_READY | BD_IIC_START | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP; This worked, and two bytes were written on the bus, leading me to believe that the CPM was at fault. Has anyone noticed the same behaviour ? Is there a workaround available ? I tried searching Freescale's website for CPM microcode updates but haven't found anything related to the I2C controller. Laurent Pinchart
About BDI2000 and mpc8247
i have a develop board based on mpc8247. It has no eeprom to restore hareware configure word and i have to use default config word 0x. my bdi config file: [...] You should tell the BDI to initialize the SYPCR register, otherwise the internal watchdog timer will keep resetting the CPU. [INIT] ; *** Initialize the core internal registers ; Program the SYPCR - Disable the watchdog timer WM320xf0010004 0x2081 You will need to initiliaze other internal registers as well (BCR, SIUMCR, BRx, ORx, ...). I'm not sure if this will be enough to solve your problem, but it should at least be a start. Laurent Pinchart
[SOLVED] MPC8248 goes berserk when printing messages on the SMC console
http://www.freescale.com/webapp/sps/utils/SingleFaq.jsp?FAQ-11241.xml Question. Board hangs when the 8260 data cache is enabled. Answer. We have found that in some systems, changing the pipline depth to 0 in the BCR register (BCR[PLDP] = 1) fixes any data cache issues. I don't know what those some systems are, but it seems that on all the others the pipeline depth must be set to 1 (BCR[PLDP] = 0). I don't know why, and it seems that Freescale doesn't either. Laurent Pinchart
Does the CPM uart driver need more memory barriers ?
Hi everybody, while trying to debug a serial port issue, I found out some code might seemed to miss write memory barriers. Does the volatile keyword guarantee that gcc will no reorder memory writes, or is the attached patched needed ? Best regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: cpm_wmb.patch Type: text/x-diff Size: 578 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060517/dbb2412a/attachment.patch
MPC8248 goes berserk when printing messages on the SMC console
Hi, after further investigation, I found out that my SMC problem is probably caused by cache issues. The SMC console works fine in U-Boot. 115200 8N1, no problem there. When booting a Linux 2.6.16 kernel, the processor doesn't print anything on the console and seems to hang. Further analysis with a BDI2000 reveals the following. - The CPU is stuck in cpm_uart_console_write, checking for while ((bdp-cbd_sc BD_SC_READY) != 0); At that point, most of the external and internal memory read as 0 (SDRAM, flash, ...). A few memory locations contain values different than 0, and I suspect those to come directly from the cache. The only memory locations that aren't filled with 0 when read from the BDI are the ones present in D-cache lines. Accessing unmapped memory doesn't fail and returns 0. - If I break right before setting the BD_SC_READY flag and run using stepi, random characters are sent on the serial port. Measuring the baudrate using an oscilloscope confirms that it has been correctly configured. Only the data is wrong.
Page fault when debugging a 2.6.16 kernel on MPC8248
Hello everybody, I'm trying to bring up Linux on a custom MPC8248 board. I've been able to setup U-Boot correctly up to the point where I boot the Linux kernel using bootm. The kernel doesn't print anything on the serial console and hangs. Thanks to a BDI2000, I've been able to get the following backtrace. #0 cpm_uart_console_write (co=0xd, s=0xc0203e4b x version 2.6.16-dirty (laurent at pclaurent) (gcc version 3.4.1) #422 Thu May 11 13:30:44 CEST 2006\n6Technotrade S.A., count=1) at drivers/serial/cpm_uart/cpm_uart_core.c:1023 #1 0xc0014144 in __call_console_drivers (start=3, end=105) at kernel/printk.c:368 #2 0xc00144f4 in release_console_sem () at kernel/printk.c:430 #3 0xc0014ce4 in register_console (console=0xc01c2e60) at kernel/printk.c:946 #4 0xc01f7308 in cpm_uart_console_init () at drivers/serial/cpm_uart/cpm_uart_core.c:1149 #5 0xc01f673c in console_init () at drivers/char/tty_io.c:3181 #6 0xc01e85b8 in start_kernel () at init/main.c:495 #7 0x in ?? () At that point, all the memory read with the BDI2000 (internal memory, SDRAM, SRAM, flash, ...) reads as 0. Knowing that something was wrong with the memory, I tried to execute the kernel step by step. Unfortunately, after breaking in start_kernel, the first gdb next command to step over the call to printk(KERN_NOTICE) hung. Hitting Ctrl-C in gdb returned the following backtrace. #0 0xc0005f4c in __delay () #1 0xc0013b18 in panic (fmt=0x487ab0 Address 0x487ab0 out of bounds) at include/asm/delay.h:42 #2 0xc001679c in do_exit (code=11) at kernel/exit.c:809 #3 0x2400c022 in ?? () #4 0xc0004b8c in die (str=0x3ff Address 0x3ff out of bounds, fp=0xc01e7c60, err=11) at arch/ppc/kernel/traps.c:101 #5 0xc000bf3c in bad_page_fault (regs=0xc01e7c60, address=0, sig=11) at arch/ppc/mm/fault.c:336 #6 0xc00046d0 in handle_page_fault () #7 0xc00046d0 in handle_page_fault () I'm lost here. Why does Linux page faults when executed step by step (or rather using next) but doesn't when running normally ? I suspect that this could be related to the memory reading as 0 in cpm_uart_console_write. Thanks in advance for all the help you can provide. Best regards, Laurent Pinchart
MPC8248 goes berserk when printing messages on the SMC console
Hi everybody, I'm trying to convince an MPC8248 board to boot Linux, and I'm having problems with the SMC console. I posted an e-mail on linuxppc-embedded regarding BDI2000 problems earlier today. The problem hasn't been solved, but I've been able to work around it by adding an infinite loop in the kernel code at the point where I want to break, halting the execution when the loop has been reached, and using gdb from there. The SMC console works fine in U-Boot. 115200 8N1, no problem there. When booting a Linux 2.6.16 kernel, the processor doesn't print anything on the console and seems to hang. Further analysis with a BDI2000 reveals the following. - The CPU is stuck in cpm_uart_console_write, checking for while ((bdp-cbd_sc BD_SC_READY) != 0); At that point, most of the external and internal memory read as 0 (SDRAM, flash, ...). A few memory locations contain values different than 0, and I suspect those to come directly from the cache. - If I break right before setting the BD_SC_READY flag and run using stepi, random characters are sent on the serial port. Measuring the baudrate using an oscilloscope confirms that it has been correctly configured. Only the data is wrong. - If I remove the lines bdp-cbd_sc |= BD_SC_READY; the kernel runs until it panics when mounting the root partition. - If I disable the SMC transmitter (by not setting SMCMR_TEN in SMCMR), the kernel hangs when wrapping around to the first buffer descriptor, waiting for it to be ready, which of course never happens. This seems to confirm that the CPM does something very armful to the CPU. I'm completely lost here, and would appreciate any help. Best regards, Laurent Pinchart
New fs_enet driver : filling platform_data
Hi everybody, I'm trying to use the new fs_enet FCC ethernet driver (drivers/net/fs_enet) with an Embedded Planet EP8284 board (LXT971A phy). I don't know how/where to fill the platform_data structure that the mii-bitbang driver uses. Could anyone give me some help, or point me to a sample implementation for a similar platform ? Best regards, Laurent Pinchart
New fs_enet driver : filling platform_data
Hi Vitaly, I have posted recently fs_enet driver update to the list - (FS_ENET: use PAL for mii management) - you'll find needed platform info updates for 8272ads and 866 ads in the patch. I am going to push it rather shortly, after I'll correct some minor issues appeared. Thanks. Which tree is your patched based on ? It doesn't apply cleanly against 2.6.16. Laurent Pinchart
CPM2 USB driver MPC8248
When I connect a USB 2.0 Mass Storage device, initialization fails when trying to fetch the string descriptors. Here's what USBMon produces (I decoded the USB transactions with the device). [snip] I had similar problems with mass storage devices (disk-on-key). I've tried to find out what was causing them but I hadn't much success with it. I think that problem might be in driver performance because it is very far from optimal. How is the driver development going ? You're not using the sourceforge CVS/SVN repository, is there another one somewhere (maybe a git tree) ? Are you actively working on performance issues, or is the development currently stalled ? What are the major performance issues ? I noticed that the driver uses the MPC82xx packet level interface. Why don't you use the transaction level interface ? Another thing that may cause problems is how storage devices treat SOF packets, but I'm not USB expert enough to be sure about that. That might explain why some devices don't even respond to the first request. I noticed that, on my EP8248 board, the controller only sends 990 SOF packets per second (or rather 990 SOF interrupts are generated). I might have a time base problem somewhere, as I computed the number of interrupts per second with a simple cat /proc/driver/m8xxhci_privateh sof.1 sleep 300 cat /proc/driver/m8xxhci_privateh sof.2 Do you have the same problem ? I'll see if I can get my hands on a USB protocol analyzer. Laurent Pinchart
CPM2 USB driver MPC8248
The driver development is stalled and I don't know when I'll be able to continue working on it. Bad news, but I do understand. Please inform me when you will resume working on the driver, so that I can inform you of the progress I will have made (if any). What are the major performance issues ? One of the issues in this driver is redunduncy between qe end ep structures and as a consequence a lot of uneeded code that make cross updates. I didn't run profiling, so I can't tell better. Ok. I noticed that the driver uses the MPC82xx packet level interface. Why don't you use the transaction level interface ? The original driver I've started with used packet level. I thought on switching to transaction level, but I hadn't time for it because of other projects pressure. Do you think it would be worth it, or are there any issue which you are aware of that would make it difficult/impractical/impossible/useless ? That might explain why some devices don't even respond to the first request. I noticed that, on my EP8248 board, the controller only sends 990 SOF packets per second (or rather 990 SOF interrupts are generated). I might have a time base problem somewhere, as I computed the number of interrupts per second with a simple cat /proc/driver/m8xxhci_privateh sof.1 sleep 300 cat /proc/driver/m8xxhci_privateh sof.2 I'm not sure such measurements are correct, since you sleep not exatly 300 seconds. I haven't measured how many SOF interrupts I get, but I think you maybe right. It may happen that during transmit or recieve the interrupts are off and SOF packets are not sent. My bad, this was caused by the boot loader passing 6600Hz instead of Hz to Linux as the bus frequency. This is fixed now, and I get 1000 SOF interrupts per second. Do you have the same problem ? I'll see if I can get my hands on a USB protocol analyzer. Good luck, I'll try to help but unfotunately I'm very much busy with other projects now. Thanks for your help already. Laurent Pinchart
CPM2 USB driver MPC8248
Hi Mike, I'm having trouble using your CPM2 USB host controller driver on an Embedded Planet EP8248 board with Linux 2.6.15. The driver didn't compiler with 2.6.15 but the required changes were minor (the root hub doesn't have to be registered by the host controller driver anymore, and a few functions have been renamed). I modified the board setup function according to my hardware (different BCSR registers) and the driver loads properly. When I connect a USB 2.0 Mass Storage device, initialization fails when trying to fetch the string descriptors. Here's what USBMon produces (I decoded the USB transactions with the device). /* Initialization */ c054a860 62948014 C Ii:001:01 0 1 D c054a860 62948089 S Ii:001:01 -115 2 D c04500e0 62948126 S Ci:001:00 s a3 00 0001 0004 4 c04500e0 62948134 C Ci:001:00 0 4 = 01010100 c04500e0 62948146 S Co:001:00 s 23 01 0010 0001 0 c04500e0 62948151 C Co:001:00 0 0 c04500e0 62948158 S Ci:001:00 s a3 00 0001 0004 4 c04500e0 62948163 C Ci:001:00 0 4 = 0101 c04500e0 62980027 S Ci:001:00 s a3 00 0001 0004 4 c04500e0 62980045 C Ci:001:00 0 4 = 0101 c04500e0 63012025 S Ci:001:00 s a3 00 0001 0004 4 c04500e0 63012042 C Ci:001:00 0 4 = 0101 c04500e0 63044025 S Ci:001:00 s a3 00 0001 0004 4 c04500e0 63044042 C Ci:001:00 0 4 = 0101 c04500e0 63076025 S Ci:001:00 s a3 00 0001 0004 4 c04500e0 63076043 C Ci:001:00 0 4 = 0101 c04500e0 63076088 S Co:001:00 s 23 03 0004 0001 0 c04500e0 63172013 C Co:001:00 0 0 c04500e0 63228024 S Ci:001:00 s a3 00 0001 0004 4 c04500e0 63228042 C Ci:001:00 0 4 = 0301 c04500e0 63284035 S Co:001:00 s 23 01 0014 0001 0 c04500e0 63284052 C Co:001:00 0 0 c04500e0 63456779 S Ci:000:00 s 80 06 0100 0040 64 c04500e0 63457301 C Ci:000:00 0 18 = 12010002 0040 81075051 2102 0301 c04500e0 63457338 S Co:001:00 s 23 03 0004 0001 0 c04500e0 63552013 C Co:001:00 0 0 c04500e0 63608025 S Ci:001:00 s a3 00 0001 0004 4 c04500e0 63608043 C Ci:001:00 0 4 = 0301 c04500e0 63664025 S Co:001:00 s 23 01 0014 0001 0 c04500e0 63664042 C Co:001:00 0 0 c04500e0 63664055 S Co:000:00 s 00 05 0002 0 c04500e0 63664590 C Co:000:00 0 0 /* GET_DESCRIPTOR DEVICE 0x12 bytes */ c04500e0 63680039 S Ci:002:00 s 80 06 0100 0012 18 c04500e0 63680781 C Ci:002:00 0 18 = 12010002 0040 81075051 2102 0301 /* GET_DESCRIPTOR CONFIGURATION 0x09 bytes */ c04500e0 63680825 S Ci:002:00 s 80 06 0200 0009 9 c04500e0 63681795 C Ci:002:00 0 9 = 09022000 01010080 32 /* GET_DESCRIPTOR CONFIGURATION 0x20 bytes */ c04500e0 63681832 S Ci:002:00 s 80 06 0200 0020 32 c04500e0 63682820 C Ci:002:00 0 32 = 09022000 01010080 32090400 00020806 5705 81024000 00070501 0240 /* GET_DESCRIPTOR STRING 0xff bytes */ c0450140 63682877 S Ci:002:00 s 80 06 0300 00ff 255 c0450140 68680032 C Ci:002:00 -104 0 /* GET_DESCRIPTOR STRING 0x02 bytes */ c0450140 68680075 S Ci:002:00 s 80 06 0300 0002 2 c0450140 73680032 C Ci:002:00 -104 0 /* GET_DESCRIPTOR STRING 0xff bytes */ c0450140 73725213 S Ci:002:00 s 80 06 0300 00ff 255 c0450140 78724036 C Ci:002:00 -104 0 /* GET_DESCRIPTOR STRING 0x02 bytes */ c0450140 78724141 S Ci:002:00 s 80 06 0300 0002 2 c0450140 83724019 C Ci:002:00 -104 0 /* GET_DESCRIPTOR STRING 0xff bytes */ c0450140 83769592 S Ci:002:00 s 80 06 0300 00ff 255 c0450140 88768017 C Ci:002:00 -104 0 /* GET_DESCRIPTOR STRING 0x02 bytes */ c0450140 88768053 S Ci:002:00 s 80 06 0300 0002 2 c0450140 93768016 C Ci:002:00 -104 0 /* SET_CONFIGURATION 1 */ c0450140 93814145 S Co:002:00 s 00 09 0001 0 c0450140 98812017 C Co:002:00 -104 0 As you can see, the devices sends its device and configuration descriptors, but something goes wrong with the string descriptors. I modified the core USB code to request 0x40 bytes (which is the value of bMaxPacketSize0) or even 0x20 bytes, but the same problem occurs (same USBMon traces with 0xff replaced by 0x40). Could you help me ? Kernel coding is not a problem, so I can make experiments if you point me to some direction. I'm also quite familiar with the USB specs down to the various types of transfers (control, interrupt, bulk and isochronous) but not with the lower-level protocol (frames, tokens, ...). I can learn if needed. Laurent Pinchart
CPM2 USB driver MPC8248
Hi, after more testing, I found out that only the first 3 control URBs complete successfully. I tried to duplicate the first GET_DESCRIPTOR(CONFIG) request, and the second one which worked before now fails. If I unplug/replug the device, the first GET_DESCRIPTOR(DEVICE) request sent to device 0 from hub_port_init fails: c0450260 133702068 S Ci:000:00 s 80 06 0100 0040 64 c0450260 134700018 C Ci:000:00 -104 0 c0450260 134700053 S Ci:000:00 s 80 06 0100 0040 64 c0450260 135700016 C Ci:000:00 -104 0 c0450260 135700049 S Ci:000:00 s 80 06 0100 0040 64 c0450260 136700018 C Ci:000:00 -104 0 Hope this helps to diagnose the problem, Laurent Pinchart
CPM2 USB driver MPC8248
I don't know if it could be of interest for you. I experienced same problem, but only with a subset of the USB storage devices I have tested. There are same which worked fine. I tried with two USB Mass Storage devices. Both fail but at different stages. Do you know if the devices you were able to access were USB 1.1 or USB 2.0 devices ? Laurent Pinchart
Accessing the CPM2 on an MPC82xx : CPM_MAP_ADDR or cpm2_immr ?
Hi everybody, I noticed that the CPM2 module is accessed both through CPM_MAP_ADDR (physical address) and cpm2_immr (ioremap()ed address). For instance, the fec_enet driver configures the IO ports using (cpm2_map_t*)CPM_MAP_ADDR. What's the correct way to access the CPM2 module ? Does ioremap() map CPM_MAP_ADDR to itself so that both ways are correct ? Laurent Pinchart
Accessing the CPM2 on an MPC82xx : CPM_MAP_ADDR or cpm2_immr ?
I noticed that the CPM2 module is accessed both through CPM_MAP_ADDR (physical address) and cpm2_immr (ioremap()ed address). For instance, the fec_enet driver configures the IO ports using (cpm2_map_t*)CPM_MAP_ADDR. Mentioned driver is deprecated. It has been replaced by drivers/net/fs_enet, right ? The new driver doesn't support the LXT971/LXT971A PHY chipsets yet, so I'm still using the old one. What's the correct way to access the CPM2 module ? Does ioremap() map CPM_MAP_ADDR to itself so that both ways are correct ? Even direct cpm2_immr usage is not a good thing, but I cannot tell more without knowing your concerns. Can you please describe what you are planning to implement, prolly we can advice how to do that proper way. I'm currently just hacking IDMA transfers to make sure the signals we plan to use on a custom design work as expected. I will later work on the USB host controller driver. The new fs_enet driver internally maps CPM_MAP_ADDR. Should every driver create an internal CPM mapping ? Why was the old fec_enet driver able to access the CPM through CPM_MAP_ADDR without ioremap()ing it first ? Laurent Pinchart
[RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
No, that's good. If you can cleanly merge the existing parsing code, by all means please do so. Thanks. Ok I will. On which kernel tree should I base my patches on ? Laurent Pinchart
[PATCH] Merge Embedded Planet board information parsers into a single function
Hi everybody, arch/ppc/boot/simple/embed_config.c has duplicate board information parsing code. This patch merges the parsers into a single function. This is the first time I use git, so please point out the mistakes I probably did. I didn't include EP8248 support in this patch, as Tom Rini pointed out that it would have to wait for 2.6.17-rc1. Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: ep-parser.patch Type: text/x-diff Size: 8222 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060131/a7d4069d/attachment.patch
[FIXED] Trouble with SMC serial port in ppc/boot/simple on Embedded Planet 8248 board
Hi, I've been able to fix the problem. I made a mistake in Linux boot code (ppc/boot/simple/embed_config.c) when computing the amount of available RAM, which resulted in Linux thinking it could access -16MB = 4080MB of RAM. Laurent Pinchart
[RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
Hi everybody, the Embedded Planet boards boot loader pass a string containing key/value pairs to the Linux loader code. That string is parsed in arch/ppc/simple/embed_boot.c. The current implementation duplicates the parsing code once for each supported board. As I'm adding support for a new EP board (EP8248), I was wondering if it would be worth merging all those parsers together. This would reduce the source code size, but would be pointless at runtime as only one board support code is compiled in the kernel anyway. Should I submit a patch, or leave the code as it is ? Laurent Pinchart
[RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
Should I submit a patch, or leave the code as it is ? Port Das U-Boot. Of course, that's another solution. We will use Das U-Boot for our custom design. What I wanted to do here is completely different. As the board comes with a proprietary boot loader, I thought it would be interesting for future users to have the board supported in the vanilla kernel, like many other boards are. Is that a mistake ? Laurent Pinchart
Trouble with SMC serial port in ppc/boot/simple on Embedded Planet8248 board
I'm trying to port the Linux kernel (2.6.15.1) to the Embedded Planet 8248 board. The board has a proprietary boot loader and uses SMC1 has a serial console. Do you have SCC1 enabled also? In arch/ppc/boot/simple/m8260_tty.c you will see that if SCC1 is enabled the early text tries to print to it, even if SMC1 is selected as the console in the config. That was about the only trick to do to get the early text. I commented that line to fix the problem, and I was thinking about either a configuration option (CONFIG_SERIAL_CONSOLE_SCCx and CONFIG_SERIAL_CONSOLE_SMCx) or a macro in the platform-specifix header file to override that. Any comment ? Laurent Pinchart
Trouble with SMC serial port in ppc/boot/simple on Embedded Planet 8248 board
Hi everybody, (First of all, this is a repost of a mail I sent yesterday for which I haven't received a copy from the mailing list and which does not appear in the archives. If the mail hasn't been dropped, sorry for the duplicate). I'm trying to port the Linux kernel (2.6.15.1) to the Embedded Planet 8248 board. The board has a proprietary boot loader and uses SMC1 has a serial console. After some work (2.6.15.1 has a nasty bug related to relocation which has been fixed in the git tree), I have been able to load and start the kernel image. Unfortunately, the early serial output is lost. Here is the kernel boot messages I get with 2.6.15.1 : - Embedded Planet EP8248 PowerPC port Built 1 zonelists Kernel command line: console=ttyCPM0,9600n8 root=/dev/ram0 rw PID hash table entries: 4096 (order: 12, 65536 bytes) Warning: real time clock seems stuck! Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 777088k available (1520k kernel code, 440k data, 96k init, 0k highmem) Mount-cache hash table entries: 512 NET: Registered protocol family 16 - And here is the same with the modified 2.6.10-pre3 kernel shipped with the board: - loaded at: 0020 002D01E8 relocated to: 0040 004D01E8 board data at: 004CE12C 004CE168 relocated to: 0040509C 004050D8 zimage at: 00405A31 004CD2C4 avail ram: 004D1000 0100 Linux/PPC load: console=ttyCPM0,9600n8 root=/dev/ram0 rw Uncompressing Linux...done. Now booting the kernel Linux version 2.6.10-rc3 (laurent at pclaurent) (gcc version 3.4.1) #5 Thu Jan 19 15:25:42 CET 2006 Embedded Planet EP8248 PowerPC port Built 1 zonelists [...] - Early boot messages (printed with puts in ppc/boot/simple/misc-embedded.c) are lost. I compared the Embedded Planet kernel with the 2.6.10-rc3 from kernel.org, haven't seen any big change related to the SMC serial port. Embedded Planet uses BRGC7 instead of BRGC1 for SMC1, but that didn't work better for me. I of course enabled the RS232 transceivers in the board control and status registers (BCSR). Could anyone give me any pointer to where I should look at ? Thanks in advance, Laurent Pinchart
Consulting - Motorola MPC860T design verification
Hi everybody, I'm designing a custom board based on an MPC860T processor (MPC860T, flash, SDRAM, serial ports, LTX971A and SpartanII). I'm looking for someone who could verify my design (you would of course be paid for the service). The schematic capture tool I use is Protel. Thanks in advance. Laurent Pinchart ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linux-2.4.18 copy-back cache mode
Hi everybody I tried to boot a FADS860T board with the 2.4.18 linux kernel, and experienced problems with cache set in Copy-Back mode. The kernel configuration help states that you can say 'Y' to Copy-Back mode if 'you don't know what that is about', so that's what I did. I then got a 'kernel access of bad area' just after the 'CPM UART driver version 0.03' message. I traced the problem to rs_8xx_init, and found out that a write to .data was causing the crash. After some more investigation I found that disabling Copy-Back mode (thus enabling Write-Through mode) fixed the problem. The problem seems to have been solved in the linuxppc repository, so the purpose if this message is not to ask for help but rather to give help to people who will experience the same problem (no doubt there will be some, as the Copy-Back mode is advised by the kernel configurator). Laurent Pinchart PS: I posted a few patches based on the latest linuxppc tree (to fix some compilation warnings and a problem with xmon) about one week ago. I got no feedback. Have they got through to the list ? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
