Strange behavior with I2C on Sequoia board

Strange behavior with I2C on Sequoia board

[Steven A. Falco]

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

Re: Strange behavior with I2C on Sequoia board

[Josh Boyer]

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

josh

Re: Strange behavior with I2C on Sequoia board

[Sean MacLennan]

On Wed, 20 Aug 2008 20:44:23 -0400
"Josh Boyer" <jwboyer@gmail.com> 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

Re: Strange behavior with I2C on Sequoia board

[Stefan Roese]

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

Re: Strange behavior with I2C on Sequoia board

[Valentine Barshak]

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

Re: Strange behavior with I2C on Sequoia board

[Steven A. Falco]

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

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

	Steve

Re: Strange behavior with I2C on Sequoia board

[Stefan Roese]

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

Re: Strange behavior with I2C on Sequoia board

[Stefan Roese]

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

Re: Strange behavior with I2C on Sequoia board

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1211 bytes --]

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

Re: Strange behavior with I2C on Sequoia board

[Stefan Roese]

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

Re: Strange behavior with I2C on Sequoia board

[Wolfgang Denk]

Dear Geert,

In message <Pine.LNX.4.64.0808211630170.20704@vixen.sonytel.be> 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

Re: Strange behavior with I2C on Sequoia board

[Wolfgang Denk]

Dear Valentine Barshak,

In message <48AD5FD1.1090809@ru.mvista.com> 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.