[Linux-ATM-General] mpc8360sar
Alex, we are working on the 8360 upstream. As the similarity between 832x and 8360, if the 8360 has benn accepted, it would be easy for 832x upstream. We have submit the 8360 patch to the opensource. But we are waiting it to be accepted. BTW, the new version QOC3-ATM card will adopt. The QOC3-ATM card code need some modification. I send the new code to you if it done. Ok ? Tony -Original Message- From: Alex Zeffertt [mailto:ajz at cambridgebroadband.com] Sent: Friday, July 21, 2006 12:15 AM To: Kumar Gala Cc: Li Tony-r64360; linux-atm-general at lists.sourceforge.net; linuxppc-embedded at ozlabs.org Subject: Re: [Linux-ATM-General] mpc8360sar Kumar Gala wrote: On Jul 20, 2006, at 8:33 AM, Alex Zeffertt wrote: Any reason we dont try to get your work up stream into the mainline kernel? - kumar I'd like to see it upstreamed - the more people who use it the more help I get! However, mpc8360sar is built on Freescale's BSP which adds basic support for the board, the MPC832xE-MDS, to the stock linux kernel. This support consists of the following patches: Patch0 : patch-2.6.11.bz2 Patch1 : linux-2.6.11-mpc8349e-general-20060414.patch Patch2 : linux-2.6.11-mpc8349e-pci-3.patch Patch3 : linux-2.6.11-mpc8349e-pci-agent.patch Patch4 : linux-2.6.11-mpc8349e-watchdog.patch Patch5 : linux-2.6.11-mpc83xx-sec2.patch Patch6 : mpc832x-sec2v15-config-1.patch Patch7 : linux-2.6.11-mpc8349e-usb-gadget.patch Patch8 : linux-2.6.11-mpc8349e-usb-host.patch Patch9 : linux-2.6.11-mpc8360-general-1.patch Patch10 : linux-2.6.11-mpc8360-pci-agent.patch Patch11 : linux-2.6.11-mpc832x-basic-4.patch Patch12 : linux-2.6.11-mpc832x-pci-agent.patch Patch13 : linux-2.6.11-mpc832x-spi-1.patch Patch14 : linux-2.6.11-mpc832x-BIT.patch Patch15 : linux-2.6.11-mpc83xx-ct-1.patch Patch16 : linux-2.6.11-mpc832x-usb-gadget.patch Patch17 : linux-2.6.11-mpc832x-atm-1.patch I guess there's no point upstreaming mpc8360sar until freescale have upstreamed these patches (and ported them to the current kernel). True, a large number of these patches are upstream, and if I had access to MPC836x or MPC832x HW I'd work on getting the others that are reasonable. Alex PS It's probable that mpc8360sar actually only requires a handful of the above patches to be applied. Agreed. - kumar Tony, can you let me know when CONFIG_MPC832XE_MDS support is upstreamed to a kernel.org kernel. I'll then try to get the mpc8360sar working with this kernel and then upstream it. Alex PS I'm not entirely sure how upstreaming is done.
Regarding MAL
Hi, i am porting a EMAC driver from NetBSD to my Xilinix ML403 embeddded board . NETBSD code is Having a Media Access Layer (MAL) , which i want to know bit , is it the same MAC layer . regards sangamesh
Can't up my eth0
Hi, I am now succefully to bring up my kernel on my PPC440GP custom board, but I failed to up my eth0, the eth0 is link down after the kernel is booting up. There is no effect, after the command ifconfig eth0 up. Can anyone tell me what may be the root case, and what reason may cause the eth0 unstable, thanks a lot. below is my log: PPC 4xx OCP EMAC driver, version 3.53 mal0: initialized, 4 TX channels, 2 RX channels zmii0: bridge in RMII mode eth0: emac0, MAC 00:01:02:54:12:47 eth0: found Generic MII PHY (0x01) emac1: can't find PHY! mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP route cache hash table entries: 4096 (order: 2, 16384 bytes) TCP established hash table entries: 16384 (order: 4, 65536 bytes) TCP bind hash table entries: 16384 (order: 4, 65536 bytes) TCP: Hash tables configured (established 16384 bind 16384) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RAMDISK: Compressed image found at block 0 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 120k init Starting pid 22, console /dev/teth0: link is down Starting pid 27, console /dev/ttyS1: '/bin/bash' Starting pid 26, console /dev/ttyS1: '/bin/application' ### Application running ... Starting pid 29, console /dev/ttyS1: '/bin/application' Thanks in advance! - Denny -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060721/512f9975/attachment.htm
Boot strategies and Boot Image formats in arch/powerpc
Hi all, currently i am trying to migrate our existing PowerPC board supports from the arch/ppc - directory into the new arch/powerpc. I am directly working within a cloned paulus_powerpc git repository on the most recent status. We (Kontron) want to bring our kernel sources into the appropriate for an open source submission. We are modifying both our proprietary Bootloader, and the Linux Kernel, to make them fit to the new conventions, e.g. the flattened device tree. However, i dont understand the following: In the old structure, the kernel provided a bunch of sub directories (simple,openfirmware,...) to create a wrapper around the Linux kernel for brining it into the format, which is appropriate for the boot loader used. This structure was easily adaptable for custom image formats. Now, these dirs dont exist any more. What is the strategy here (i could assume one the 3 variants below ? a) Is it now in the responsibility of the bootloader, to support one of the image formats, which can be generated here currently ? b) Will these subdirs (e.g. simple) come here, but just where not ported yet ? c) Or, shall such wrapper around the kernel, and/or bringing the kernel into a particular file format be performed outside the kernel source, by proprietary tools (e.g. like U-boot does it with the mkimage tool) ? -- Mit freundlichen Gruessen / Best regards Claus Gindhart SW RD Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron-modular.com http://www.kontron.com -BEGIN GEEK CODE BLOCK- Version: 3.1 GU d- s++:++:+ a+ C++$ !U !P L++$ E-- W+(-) N- o? K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++ D-- G e++ h--- !r x+++ --END GEEK CODE BLOCK-- -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060721/927c8511/attachment.htm
Boot strategies and Boot Image formats in arch/powerpc
On Fri, 21 Jul 2006 11:35:25 +0200 Claus Gindhart claus.gindhart at kontron.com wrote: Hi all, currently i am trying to migrate our existing PowerPC board supports from the arch/ppc - directory into the new arch/powerpc. I am directly working within a cloned paulus_powerpc git repository on the most recent status. We (Kontron) want to bring our kernel sources into the appropriate for an open source submission. We are modifying both our proprietary Bootloader, and the Linux Kernel, to make them fit to the new conventions, e.g. the flattened device tree. However, i dont understand the following: In the old structure, the kernel provided a bunch of sub directories (simple,openfirmware,...) to create a wrapper around the Linux kernel for brining it into the format, which is appropriate for the boot loader used. This structure was easily adaptable for custom image formats. Now, these dirs dont exist any more. Well, in arch/powerpc those stuff had no sense so far.. But it may change - see below. What is the strategy here (i could assume one the 3 variants below ? a) Is it now in the responsibility of the bootloader, to support one of the image formats, which can be generated here currently ? This way we have started with powerpc merge and it still could be used. there are plenty of such stuff in the list archives, being discussed, and even followed up with patches. But that imply u-boot firmware so not interesting for you I assume. b) Will these subdirs (e.g. simple) come here, but just where not ported yet ? Currently, Mark is working on a thing similar to this case. the kernel building zImage has to compile devicetree to binary dtb and line stuff up so that booting, the shim has started the kernel and have devicetree passed to it. c) Or, shall such wrapper around the kernel, and/or bringing the kernel into a particular file format be performed outside the kernel source, by proprietary tools (e.g. like U-boot does it with the mkimage tool) ? This was yet another way pondered, but I guess b) looked better. -- Mit freundlichen Gruessen / Best regards Claus Gindhart SW RD Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart at kontron-modular.com http://www.kontron.com -BEGIN GEEK CODE BLOCK- Version: 3.1 GU d- s++:++:+ a+ C++$ !U !P L++$ E-- W+(-) N- o? K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++ D-- G e++ h--- !r x+++ --END GEEK CODE BLOCK-- -- Sincerely, Vitaly
problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
-- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060721/820107f6/attachment.htm
problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
Hi Arun, On Fri, 2006-07-21 at 20:26 +0530, Arun Kumar wrote: Hi , Can anyone help me in this naive problem ? Then a naive answer is most fitting... Turns out that's my specialty. # # Memory Technology Devices (MTD) # CONFIG_MTD=y CONFIG_MTD_DEBUG=y CONFIG_MTD_DEBUG_VERBOSE=2 CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CONCAT=y CONFIG_MTD_REDBOOT_PARTS=y CONFIG_MTD_CMDLINE_PARTS=y Probably get rid of REDBOOT if you're not using that bootloader # # User Modules And Translation Layers # # CONFIG_MTD_CHAR is not set # CONFIG_MTD_BLOCK is not set # CONFIG_MTD_BLOCK_RO is not set # CONFIG_FTL is not set # CONFIG_NFTL is not set # CONFIG_INFTL is not set You need to enable MTD_CHAR to read/write and MTD_BLOCK to mount Can any happy soul let me know :-- 1)How to mount jffs2 on this flash and also to test mtd-read/write routines ? Start with the char drivers (/dev/mtd0 etc.). You'll need one for each partition you want to experiment with. How about creating the nodes manually? mknod /dev/mtd0 c 90 0 mknod /dev/mtd1 c 90 2 etc. (minor # increments in 2s) Add a block device for each partition: mknod /dev/mtdblock0 b 31 0 mknod /dev/mtdblock1 b 31 1 etc. Once you clean up #3 below, you should be able to read/write the char devices using commands like 'cat', or write a simple user-space app using open, read, write, etc if you'd rather look at the actual binary data. You can then experiment with mounting the JFFS2. I recommend booting to an NFS file system then mounting the JFFS2 with something like: mount -t jffs2 /dev/mtdblock5 /mnt/temp(Use the correct partition) 2) Is it ok not to see mtd0.. partions in /dev directory . Pretty sure you'll need these 3 ) Where do I register the mtd partitions to get them noticed here ?? Looks like your partitions are already being found, but are probably not set up right. I don't know if this is a static definition in your board init code or passed by command line from the bootloader, but it looks like the values don't line up with your device: * Using physmap partition definition Creating 3 MTD partitions on phys_mapped_flash: 0x-0x0004 : foo-ets0 mtd: Giving out device 0 to foo-ets0 0x0004-0x001e : foo-ets1 mtd: partition agere-ets1 doesn't end on an erase block -- force read-only mtd: Giving out device 1 to foo-ets1 0x001e-0x0020 : foo-ets2 mtd: partition foo-ets2 doesn't start on an erase block boundary -- force read-only * -- Hopefully this helps you proceed a little bit. regards, Ben
Boot problem on Sandpoint
Hi all, I have to port Linux on a Sandpoint Board wtih a MPC8241 processor on. I built a kernel using linux 2.6.15 and create an zImage.initrd.elf with a ramdisk. All of this (linux and ramdisk) was packaged with ELDK 4.0. I also minimized everything in the .config file to only have what is really necessary (serial port, 6xx processor, etc). The communication is made with the board by its internal serial port and Dink32 is used to do everything else. The problem is that when I execute the loaded zImage.initrd.elf, the boot sequence just hangs there and I just don't see anything happening. There is nothing that is displayed. I know that the elf file as an offset header of 0X1, so the problem is not there. I also put some breakpoints and trace using Dink32 to see where it stops and it may have something to do with the disable_6xx_mmu in the utils.S file. I just really don't know what's wrong in my config and I hope someone could help me on this. Thank you Benoit Lajoie-Dorval
Boot problem on Sandpoint
On Fri, Jul 21, 2006 at 11:49:14AM -0700, Benoit Lajoie-Dorval wrote: Hi all, I have to port Linux on a Sandpoint Board wtih a MPC8241 processor on. Tell your boss that it'll take 3 months including lots of overtime, then crack open a beer! The sandpoint/8241 has been working for years. built a kernel using linux 2.6.15 and create an zImage.initrd.elf with a ramdisk. All of this (linux and ramdisk) was packaged with ELDK 4.0. I also minimized everything in the .config file to only have what is really necessary (serial port, 6xx processor, etc). The communication is made with the board by its internal serial port and Dink32 is used to do everything else. The problem is that when I execute the loaded zImage.initrd.elf, the boot sequence just hangs there and I just don't see anything happening. There is nothing that is displayed. I know that the elf file as an offset header of 0X1, so the problem is not there. I also put some breakpoints and trace using Dink32 to see where it stops and it may have something to do with the disable_6xx_mmu in the utils.S file. I just really don't know what's wrong in my config and I hope someone could help me on this. Well, you did lots of things that could have broken it. Go back to square one: default .config with nfs mounted rootfs. Get that to work then tune the .config and add a ramdisk. Also, if you have a bdi2000 or some other jtag/cops debugger, you can dump __log_buf and see if there is anything there. Mark
stupid linker question....
I forgot the flag that generates a list file that has both assembly and c mixed in. Anyone? Thanks... -stv
stupid linker question....
gcc -Wa,-alhs -g main.c main.cs will put interleaved code/assembly into main.cs file. wade On 7/21/06, Steve Iribarne (GMail) netstv at gmail.com wrote: I forgot the flag that generates a list file that has both assembly and c mixed in. Anyone? Thanks... -stv ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060721/7cf09116/attachment.htm
