AM335x EEPROM disable

Thanks for the fast reply,

This may be a newbie question but what do you mean by workaround?

Can we hardcode the header?

I mean editing the code to suit your needs, since you won't be using an EEPROM IC.

Yes, you can hardcode the header and this is probably the fastest approach. The other approach is to remove all the EEPROM header data checks from the code. The second approach results in cleaner and more readable code, but this decision is up to you.

Best regards,
Miroslav

I recommend taking the board port u-boot instead of the main SDK u-boot and adding support for your board to that. As Miroslav has mentioned the main u-boot has a lot of code your board does not need. The board port u-boot is a stripped down version of the SDK version without a lot of the 'fluff.' This is based on the BeagleBone. 

You can take this code and add support for individual features of your board. Note that you won't necessarily have to have u-boot support for everything except what is crucial to boot the kernel (e.g. if you are not mounting an NFS or using tftp to copy the kernel u-boot doesn't need Ethernet support). 

The board port tree can be found inside board-support/board-port-labs. You can find some lecture material here which helps explain how to add new feature support.

Hi Laurens,

      Do you really need EEPROM in your custom board. If not then just comment eeprom part of code in u-boot and also kernel, The part of the code is present in board files of both u-boot and kernel.

   This will save your time, your board will be up and running.

Comment from if (read_eeprom() < 0) till the line before #endif

Add the code of ram init depending upon the board i.e., SK-EVM or GP-EVM

Note: TI used EEPROM in all its EVMs to differentiate between SK-EVM, GP-EVM.. so which are built around am335x.

Regards,

Chinna.

Hi,

I have a query about this.Now I want to add eeprom on my baseborad and only can use I2C1, I have already modified some code in kernel 3.2,include configure i2c1_pin_mux  and others as follows:

static struct pinmux_config i2c1_pin_mux[] = {
{"spi0_d1.i2c1_sda", OMAP_MUX_MODE2 | AM33XX_SLEWCTRL_SLOW |
AM33XX_PIN_INPUT_PULLUP},
{"spi0_cs0.i2c1_scl", OMAP_MUX_MODE2 | AM33XX_SLEWCTRL_SLOW |
AM33XX_PIN_INPUT_PULLUP},
{NULL, 0},
};

static struct at24_platform_data am335x_baseboard_eeprom_info_i2c1 = {
.byte_len = (32*1024) / 8,
.page_size = 32,
.flags = AT24_FLAG_ADDR16,
};

static struct i2c_board_info am335x_i2c1_boardinfo[] = {

{

/* Baseboard board EEPROM */
I2C_BOARD_INFO("24c32", 0x50),
.platform_data = &am335x_baseboard_eeprom_info_i2c1,

},

};

setup_pin_mux(i2c1_pin_mux); 

omap_register_i2c_bus(2, 100, am335x_i2c1_boardinfo,ARRAY_SIZE(am335x_i2c1_boardinfo));

This modify all based on board-am335xevm.c 

My eeprom chip is 24LC32A 

But now i meet some question :

root@am335x-evm:~# dmesg | grep omap_i2c
[ 0.129058] omap_i2c.1: alias fck already exists
[ 0.129821] omap_i2c.2: alias fck already exists
[ 0.208312] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100 kHz
[ 0.227447] omap_i2c omap_i2c.2: bus 2 rev2.4.0 at 100 kHz
[ 1.177276] omap_i2c.3: alias fck already exists
[ 1.182922] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz
[ 1.496795] omap_i2c omap_i2c.2: Arbitration lost
[ 2.513793] omap_i2c omap_i2c.2: timeout waiting for bus ready
[ 3.533813] omap_i2c omap_i2c.2: timeout waiting for bus ready
[ 4.553802] omap_i2c omap_i2c.2: timeout waiting for bus ready
[ 5.573822] omap_i2c omap_i2c.2: timeout waiting for bus ready
[ 6.593811] omap_i2c omap_i2c.2: timeout waiting for bus ready
[ 7.613800] omap_i2c omap_i2c.2: timeout waiting for bus ready
[ 8.633819] omap_i2c omap_i2c.2: timeout waiting for bus ready

root@am335x-evm:~# i2cdetect -r 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: [ 2558.385070] omap_i2c omap_i2c.2: timeout waiting for bus ready
-- [ 2558.392089] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2558.399078] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2558.416839] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2559.435058] omap_i2c omap_i2c.2: timeout waiting for bus ready
-- [ 2560.455047] omap_i2c omap_i2c.2: timeout waiting for bus ready
-- [ 2560.462097] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2560.468292] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2561.505035] omap_i2c omap_i2c.2: timeout waiting for bus ready
-- [ 2561.511840] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2562.535034] omap_i2c omap_i2c.2: timeout waiting for bus ready
-- [ 2562.541778] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2563.565032] omap_i2c omap_i2c.2: timeout waiting for bus ready
--
10: [ 2564.585052] omap_i2c omap_i2c.2: timeout waiting for bus ready
-- [ 2564.591918] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2564.597961] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2564.603546] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2564.625366] omap_i2c omap_i2c.2: Arbitration lost
-- [ 2565.665039] omap_i2c omap_i2c.2: timeout waiting for bus ready

And i really don't know what to do,could anyone help me solve the problem , thanks a lot.

I don't agree that this question has been adequately resolved.

The situation as it now exists forces every user of the AM335x to either include a compatible EEPROM (tell our hardware guys to add a cost/space item to our board) or become responsible for a deviation to an existing board image that places us squarely into writing a substantial amount of code that must adhere to GPL licensing terms.

This splinters the AM335x community into a widely divergent collection of board configs for which each user must be responsible for compliance with GPL distribution.   Roughly the same situation for U-Boot that launched Linus into a tirade that resulted in the device-tree organization for Linux

What is needed is some technical leadership from TI to help advance the Sitara product family and make it a device that is much easier for OEM's developing highly specialized devices to adopt.

1.  A much better abstraction for board identification than scattered I2C calls.   This way, most of the board implementation could be uniform excepting for a small tailoring section more easily configured by OEM's.

2. LGPL terms for the device-tree include files provided by TI

3. An implementation of CONFIG_FIT something like zynq:

    http://www.denx.de/wiki/pub/U-Boot/Documentation/multi_image_booting_scenarios.pdf

4. Use of device tree/configuration in U-Boot to select the board identification method to allow techniques other than a specific eeprom on a specific I2C bus.