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)

54 more lines

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

54 more quoted 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...

josh

On Wed, 20 Aug 2008 20:44:23 -0400
"Josh Boyer" [off-list ref] 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

On Thursday 21 August 2008, Sean MacLennan wrote:

quoted

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

Stefan Roese wrote:

On Thursday 21 August 2008, Sean MacLennan wrote:

quoted

quoted

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

Thanks,
Valentine.

Best regards,
Stefan
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Valentine Barshak wrote:

Stefan Roese wrote:

quoted

On Thursday 21 August 2008, Sean MacLennan wrote:

quoted

quoted

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

1 more quoted lines

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.

So basically, I understand the components, but I'm not yet sure how to glue it
all together.

	Steve

On Thursday 21 August 2008, Valentine Barshak wrote:

quoted

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?

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: office@denx.de
=====================================================================

On Thursday 21 August 2008, Steven A. Falco wrote:

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.

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

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

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:   Geert.Uytterhoeven@sonycom.com
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

On Thursday 21 August 2008, Geert Uytterhoeven wrote:

On Thu, 21 Aug 2008, Steven A. Falco wrote:

quoted

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

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: office@denx.de
=====================================================================

Dear Geert,

In message [off-list ref] 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 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...

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: wd@denx.de
A conservative is a man who believes that nothing should be done for
the first time.                                   - Alfred E. Wiggam

Dear Valentine Barshak,

In message [off-list ref] 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 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 */

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: wd@denx.de
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.