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 fd400000 ...

   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: 00400000
Entry Point: 00400454
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading init Ramdisk from Legacy Image at fd900000 ...

   Image Name:   initramfs
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    2442283 Bytes =  2.3 MB

Load Address: 00000000
Entry Point: 00000000
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/serial@ef600300: clock-frequency <- a8c000 (11MHz) /plb/opb/serial@ef600400: clock-frequency <- a8c000 (11MHz) /plb/opb/serial@ef600500: clock-frequency <- a8c000 (11MHz) /plb/opb/serial@ef600600: clock-frequency <- a8c000 (11MHz) Memory <- <0x0 0x0 0xffff000> (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 0x00400000 (sp: 0x0ff0d220) Allocating 0x3dbc2c bytes for kernel ...
gunzipping (0x00000000 <- 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 fd400000 ...

   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: 00400000
Entry Point: 00400454
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading init Ramdisk from Legacy Image at fd900000 ...

   Image Name:   initramfs
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    2442283 Bytes =  2.3 MB

Load Address: 00000000
Entry Point: 00000000
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/serial@ef600300: clock-frequency <- a8c000 (11MHz) /plb/opb/serial@ef600400: clock-frequency <- a8c000 (11MHz) /plb/opb/serial@ef600500: clock-frequency <- a8c000 (11MHz) /plb/opb/serial@ef600600: clock-frequency <- a8c000 (11MHz) Memory <- <0x0 0x0 0xffff000> (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 0x00400000 (sp: 0x0ff0d220) Allocating 0x3e1c48 bytes for kernel ...
gunzipping (0x00000000 <- 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...

Quoted 4 lines

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?

Quoted 4 lines · Sean MacLennan

Quoted 4 lines

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...

Quoted 2 lines

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
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Quoted 11 lines · Stefan Roese

Quoted 6 lines · Sean MacLennan

Quoted 4 lines

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.

Quoted 9 lines

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 0x400000 (Load Address: 00400000) 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 8<<20 to 8<<21 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.

I would like to switch over to using a uImage rather than the cuboot.uImage.

Quoted 2 lines · Steven A. Falco

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 00100000 ...
|    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: 00000000
|    Entry Point:  00000000
|    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)

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 00100000 ...
|    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: 00000000
|    Entry Point:  00000000
|    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...

Quoted 8 lines

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 0x400000 (Load Address: 00400000) 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?

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 0x400000 (Load Address: 00400000) 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 */