Re: Strange behavior with I2C on Sequoia board
On Thursday 21 August 2008, Sean MacLennan wrote: That's all output from the wrapper, not the kernel. And the kernel config doesn't make a difference at all to the wrapper. I wonder if there is some weird size issue going on there or if whatever U-Boot version you are using is doing odd things... Any chance something in the DTS could affect it? Maybe try commenting out the second IIC controller? Yes, I2C is generally working and should make a difference in Linux kernel booting. It seems that your bootwrapper is somehow not copying the correct MAC address to the device-tree. Not sure what's going wrong here. We usually don't use the bootwrapper but boot the uImage directly from U-Boot on all 4xx systems. You might want to debug the bootwrapper code, if possible drop the bootwrapper and use the uImage with a newer, device-tree enabled U-Boot version. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
Stefan Roese wrote: On Thursday 21 August 2008, Sean MacLennan wrote: That's all output from the wrapper, not the kernel. And the kernel config doesn't make a difference at all to the wrapper. I wonder if there is some weird size issue going on there or if whatever U-Boot version you are using is doing odd things... Any chance something in the DTS could affect it? Maybe try commenting out the second IIC controller? Yes, I2C is generally working and should make a difference in Linux kernel booting. It seems that your bootwrapper is somehow not copying the correct MAC address to the device-tree. Not sure what's going wrong here. We usually don't use the bootwrapper but boot the uImage directly from U-Boot on all 4xx systems. You might want to debug the bootwrapper code, if possible drop the bootwrapper and use the uImage with a newer, device-tree enabled U-Boot version. U-boot thinks that all memory above the first 8MB is out of reach for the kernel and puts kernel bootargs and boardinfo structure below 8MB as close as possible to this limit. Including the i2c driver into the kernel increases the kernel image size. So when u-boot unpacks the kernel to 0x40 (Load Address: 0040) it overwrites the kernel parameters. So when the kernel actually starts, it reads zeros instead of boardinfo (and mac addresses) The 8MB limit is set for all AMCC boards in include/configs/amcc-common.h: #define CFG_BOOTMAPSZ (8 20) /* Initial Memory map for Linux */ I think this limit is obsolete and can be moved to at least 64MB. But you'll need to rebuild u-boot. Stefan, what do you think? Can we increase the default initial memory map for AMCC boards in the next u-boot release, since u-boot has all memory identity-mapped on ppc 44x? Thanks, Valentine. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
Valentine Barshak wrote: Stefan Roese wrote: On Thursday 21 August 2008, Sean MacLennan wrote: That's all output from the wrapper, not the kernel. And the kernel config doesn't make a difference at all to the wrapper. I wonder if there is some weird size issue going on there or if whatever U-Boot version you are using is doing odd things... Any chance something in the DTS could affect it? Maybe try commenting out the second IIC controller? Yes, I2C is generally working and should make a difference in Linux kernel booting. It seems that your bootwrapper is somehow not copying the correct MAC address to the device-tree. Not sure what's going wrong here. We usually don't use the bootwrapper but boot the uImage directly from U-Boot on all 4xx systems. You might want to debug the bootwrapper code, if possible drop the bootwrapper and use the uImage with a newer, device-tree enabled U-Boot version. U-boot thinks that all memory above the first 8MB is out of reach for the kernel and puts kernel bootargs and boardinfo structure below 8MB as close as possible to this limit. Including the i2c driver into the kernel increases the kernel image size. So when u-boot unpacks the kernel to 0x40 (Load Address: 0040) it overwrites the kernel parameters. So when the kernel actually starts, it reads zeros instead of boardinfo (and mac addresses) The 8MB limit is set for all AMCC boards in include/configs/amcc-common.h: #define CFG_BOOTMAPSZ(8 20) /* Initial Memory map for Linux */ I think this limit is obsolete and can be moved to at least 64MB. But you'll need to rebuild u-boot. Stefan, what do you think? Can we increase the default initial memory map for AMCC boards in the next u-boot release, since u-boot has all memory identity-mapped on ppc 44x? Your diagnosis is correct! I changed the define from 820 to 821 and it now boots. Previously the parameters were at 7ffe70, and this change moved them to fffe70. I would like to switch over to using a uImage rather than the cuboot.uImage. But I have not figured out whether it is the U-boot build that converts the .dts to a .dtb or if the kernel build should do that. Also, I have not figured out whether the .dtb can remain part of the kernel image, as it is with the cuboot kernel, or if the .dtb must be a separate image in a different part of the rom. So basically, I understand the components, but I'm not yet sure how to glue it all together. Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
On Thursday 21 August 2008, Valentine Barshak wrote: It seems that your bootwrapper is somehow not copying the correct MAC address to the device-tree. Not sure what's going wrong here. We usually don't use the bootwrapper but boot the uImage directly from U-Boot on all 4xx systems. You might want to debug the bootwrapper code, if possible drop the bootwrapper and use the uImage with a newer, device-tree enabled U-Boot version. U-boot thinks that all memory above the first 8MB is out of reach for the kernel and puts kernel bootargs and boardinfo structure below 8MB as close as possible to this limit. Including the i2c driver into the kernel increases the kernel image size. So when u-boot unpacks the kernel to 0x40 (Load Address: 0040) it overwrites the kernel parameters. So when the kernel actually starts, it reads zeros instead of boardinfo (and mac addresses) The 8MB limit is set for all AMCC boards in include/configs/amcc-common.h: #define CFG_BOOTMAPSZ (8 20) /* Initial Memory map for Linux */ I think this limit is obsolete and can be moved to at least 64MB. But you'll need to rebuild u-boot. Stefan, what do you think? Can we increase the default initial memory map for AMCC boards in the next u-boot release, since u-boot has all memory identity-mapped on ppc 44x? Yes, it was our intention to increase the default map to a higher value a few weeks ago. I just forgot to really do it. I'll do this shortly. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
On Thursday 21 August 2008, Steven A. Falco wrote: Your diagnosis is correct! I changed the define from 820 to 821 and it now boots. Previously the parameters were at 7ffe70, and this change moved them to fffe70. Good. I would like to switch over to using a uImage rather than the cuboot.uImage. But I have not figured out whether it is the U-boot build that converts the .dts to a .dtb or if the kernel build should do that. The dts is part of the kernel source, so its part of the kernel build procedure. You can either do this by hand or use the make kilauea.dtb target. See also: http://www.denx.de/wiki/DULG/LinuxFDTBlob Also, I have not figured out whether the .dtb can remain part of the kernel image, as it is with the cuboot kernel, or if the .dtb must be a separate image in a different part of the rom. When you use uImage, then U-Boot needs the dtb additionally to the kernel image. Those two images (and more) can be combined to a single image using the new U-Boot image format FIT (Flattened Image Tree) though. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
On Thu, 21 Aug 2008, Steven A. Falco wrote: I would like to switch over to using a uImage rather than the cuboot.uImage. Can you actually boot a plain uImage from U-Boot? I've just gave it a try. While arch/powerpc/boot/cuImage.sequoia boots fine, after `make uImage', I get arch/powerpc/boot/uImage, but it doesn't boot: | ## Booting image at 0010 ... |Image Name: Linux-2.6.27-rc4-dirty |Image Type: PowerPC Linux Kernel Image (gzip compressed) |Data Size:1398827 Bytes = 1.3 MB |Load Address: |Entry Point: |Verifying Checksum ... OK |Uncompressing Kernel Image ... Error: inflate() returned -3 | GUNZIP ERROR - must RESET board to recover | | U-Boot 1.2.0-gc0c292b2 (Jun 5 2007 - 07:16:12) and I'm back to U-Boot... With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
On Thursday 21 August 2008, Geert Uytterhoeven wrote: On Thu, 21 Aug 2008, Steven A. Falco wrote: I would like to switch over to using a uImage rather than the cuboot.uImage. Can you actually boot a plain uImage from U-Boot? Sure. We did this all the time in arch/ppc. Now in arch/powerpc all you need is an device-tree enabled U-Boot version. This is standard for most targets since a few months. I've just gave it a try. While arch/powerpc/boot/cuImage.sequoia boots fine, after `make uImage', I get arch/powerpc/boot/uImage, but it doesn't boot: | ## Booting image at 0010 ... |Image Name: Linux-2.6.27-rc4-dirty |Image Type: PowerPC Linux Kernel Image (gzip compressed) |Data Size:1398827 Bytes = 1.3 MB |Load Address: |Entry Point: |Verifying Checksum ... OK |Uncompressing Kernel Image ... Error: inflate() returned -3 | GUNZIP ERROR - must RESET board to recover Try a higher load address for the kernel. 4MB is a good value. | U-Boot 1.2.0-gc0c292b2 (Jun 5 2007 - 07:16:12) Ups. This is most likely too old and can't boot arch/powerpc uImage files. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
Dear Geert, In message [EMAIL PROTECTED] you wrote: Can you actually boot a plain uImage from U-Boot? yes, of course you can (you will need a device tree, too). I've just gave it a try. While arch/powerpc/boot/cuImage.sequoia boots fine, after `make uImage', I get arch/powerpc/boot/uImage, but it doesn't boot: | ## Booting image at 0010 ... |Image Name: Linux-2.6.27-rc4-dirty |Image Type: PowerPC Linux Kernel Image (gzip compressed) |Data Size:1398827 Bytes = 1.3 MB |Load Address: |Entry Point: |Verifying Checksum ... OK |Uncompressing Kernel Image ... Error: inflate() returned -3 | GUNZIP ERROR - must RESET board to recover | | U-Boot 1.2.0-gc0c292b2 (Jun 5 2007 - 07:16:12) and I'm back to U-Boot... See the FAQ: http://www.denx.de/wiki/view/DULG/LinuxUncompressingError Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] A conservative is a man who believes that nothing should be done for the first time. - Alfred E. Wiggam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
Dear Valentine Barshak, In message [EMAIL PROTECTED] you wrote: U-boot thinks that all memory above the first 8MB is out of reach for the kernel and puts kernel bootargs and boardinfo structure below 8MB as close as possible to this limit. Including the i2c driver into the kernel increases the kernel image size. So when u-boot unpacks the kernel to 0x40 (Load Address: 0040) it overwrites the kernel parameters. So when the kernel actually starts, it reads zeros instead of boardinfo (and mac addresses) The 8MB limit is set for all AMCC boards in include/configs/amcc-common.h: #define CFG_BOOTMAPSZ (8 20) /* Initial Memory map for Linux */ See also the initrd_high environment variable to adjust the limits without need for recompiling U-Boot. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] The complexity of software is an essential property, not an acciden- tal one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence.- Fred Brooks, Jr. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Strange behavior with I2C on Sequoia board
I have just tried enabling I2C on a Sequoia board (kernel is DENX 2.6.26) and doing that appears to corrupt the u-boot / kernel communications. Prior to turning on I2C, I see the ethernet mac and kernel command line correctly passed, but once I turn on I2C, the ethernet mac becomes 0 and the kernel command line is missing many parameters. I'll paste in a good log, then a bad one. The only configuration difference is that the bad one has CONFIG_I2C_CHARDEV=y and CONFIG_I2C_IBM_IIC=y in the configuration. I'll start digging into it, but if anyone has any experience or ideas regarding I2C on PPC440, I'd appreciate your thoughts on this. Steve Good log: = ## Booting kernel from Legacy Image at fd40 ... Image Name: Linux-2.6.26.1-00033-g088efe4-di Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1801234 Bytes = 1.7 MB Load Address: 0040 Entry Point: 00400454 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading init Ramdisk from Legacy Image at fd90 ... Image Name: initramfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:2442283 Bytes = 2.3 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fcb8000, end 0ff0c42b ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) Memory - 0x0 0x0 0x000 (255MB) ENET0: local-mac-address - 00:10:ec:01:04:d0 ENET1: local-mac-address - 00:10:ec:01:04:d1 zImage starting: loaded at 0x0040 (sp: 0x0ff0d220) Allocating 0x3dbc2c bytes for kernel ... gunzipping (0x - 0x0040e000:0x007ed9c8)...done 0x39c1c4 bytes Using loader supplied ramdisk at 0xfcb8000-0xff0c42b initrd head: 0x1f8b0808 Linux/PowerPC load: root=/dev/sda3 rw ip=137.237.178.105:137.237.179.31:137.237.178.1:255.255.255.0:hydra_temp:eth0:off panic=1 console=ttyS0,115200 Bad log: ## Booting kernel from Legacy Image at fd40 ... Image Name: Linux-2.6.26.1-00034-gf084326-di Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1811651 Bytes = 1.7 MB Load Address: 0040 Entry Point: 00400454 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading init Ramdisk from Legacy Image at fd90 ... Image Name: initramfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:2442283 Bytes = 2.3 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fcb8000, end 0ff0c42b ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) Memory - 0x0 0x0 0x000 (255MB) ENET0: local-mac-address - 00:00:00:00:00:00 ENET1: local-mac-address - 00:00:00:00:00:00 zImage starting: loaded at 0x0040 (sp: 0x0ff0d220) Allocating 0x3e1c48 bytes for kernel ... gunzipping (0x - 0x0040e000:0x007f3a24)...done 0x3a21c4 bytes Using loader supplied ramdisk at 0xfcb8000-0xff0c42b initrd head: 0x1f8b0808 Linux/PowerPC load: console=ttyS0,115200 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
On Wed, 2008-08-20 at 16:55 -0400, Steven A. Falco wrote: I have just tried enabling I2C on a Sequoia board (kernel is DENX 2.6.26) and doing that appears to corrupt the u-boot / kernel communications. Prior to turning on I2C, I see the ethernet mac and kernel command line correctly passed, but once I turn on I2C, the ethernet mac becomes 0 and the kernel command line is missing many parameters. I'll paste in a good log, then a bad one. The only configuration difference is that the bad one has CONFIG_I2C_CHARDEV=y and CONFIG_I2C_IBM_IIC=y in the configuration. I'll start digging into it, but if anyone has any experience or ideas regarding I2C on PPC440, I'd appreciate your thoughts on this. Steve Good log: = ## Booting kernel from Legacy Image at fd40 ... Image Name: Linux-2.6.26.1-00033-g088efe4-di Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1801234 Bytes = 1.7 MB Load Address: 0040 Entry Point: 00400454 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading init Ramdisk from Legacy Image at fd90 ... Image Name: initramfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:2442283 Bytes = 2.3 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fcb8000, end 0ff0c42b ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) Memory - 0x0 0x0 0x000 (255MB) ENET0: local-mac-address - 00:10:ec:01:04:d0 ENET1: local-mac-address - 00:10:ec:01:04:d1 zImage starting: loaded at 0x0040 (sp: 0x0ff0d220) Allocating 0x3dbc2c bytes for kernel ... gunzipping (0x - 0x0040e000:0x007ed9c8)...done 0x39c1c4 bytes Using loader supplied ramdisk at 0xfcb8000-0xff0c42b initrd head: 0x1f8b0808 Linux/PowerPC load: root=/dev/sda3 rw ip=137.237.178.105:137.237.179.31:137.237.178.1:255.255.255.0:hydra_temp:eth0:off panic=1 console=ttyS0,115200 Bad log: ## Booting kernel from Legacy Image at fd40 ... Image Name: Linux-2.6.26.1-00034-gf084326-di Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1811651 Bytes = 1.7 MB Load Address: 0040 Entry Point: 00400454 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading init Ramdisk from Legacy Image at fd90 ... Image Name: initramfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:2442283 Bytes = 2.3 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fcb8000, end 0ff0c42b ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) Memory - 0x0 0x0 0x000 (255MB) ENET0: local-mac-address - 00:00:00:00:00:00 ENET1: local-mac-address - 00:00:00:00:00:00 zImage starting: loaded at 0x0040 (sp: 0x0ff0d220) Allocating 0x3e1c48 bytes for kernel ... gunzipping (0x - 0x0040e000:0x007f3a24)...done 0x3a21c4 bytes Using loader supplied ramdisk at 0xfcb8000-0xff0c42b initrd head: 0x1f8b0808 Linux/PowerPC load: console=ttyS0,115200 That's all output from the wrapper, not the kernel. And the kernel config doesn't make a difference at all to the wrapper. I wonder if there is some weird size issue going on there or if whatever U-Boot version you are using is doing odd things... josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
On Wed, 20 Aug 2008 20:44:23 -0400 Josh Boyer [EMAIL PROTECTED] wrote: That's all output from the wrapper, not the kernel. And the kernel config doesn't make a difference at all to the wrapper. I wonder if there is some weird size issue going on there or if whatever U-Boot version you are using is doing odd things... Any chance something in the DTS could affect it? Maybe try commenting out the second IIC controller? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
