How to enable i2c at u-boot stage


Go to solution Solved by J.M.,

Recommended Posts

Hi,

 

I'm trying to enable the I2C at the U-BOOT stage, but so for with no success.

I'm using Lamobo-R1 (Allwinner A20), but I guess that general tips from similar boards (Banana PI etc.) are still very welcome.

 

I read these posts, and tried what has been suggested here, but with no success :(

I2C control in u-boot: Orange Pi Zero

enable i2c at u-boot for NanoPi Neo2

u-boot with I2C

 

This is what I've done so far:

  1. I've modified the u-boot device tree to enable the I2C bus (I did the same with the kernel device-tree, and here it does work!!)
  2. I've added to Lamobo_R1_deconfig the next configurations:

    CONFIG_I2C0_ENABLE=y

    CONFIG_I2C1_ENABLE=y

    CONFIG_I2C2_ENABLE=y

    CONFIG_I2C3_ENABLE=y

    CONFIG_I2C4_ENABLE=y

  3. Add new overlays to /boot/armbianEnv.txt: 
    overlays=i2c1 i2c2 i2c3 i2c4
  4. Since it didn't help, I've added the following (as suggested from the posts) to Lamobo_R1_deconfig, but it causes compilations issues - I believe I have a collision between configurations, but I didn't figure out what configuration cause the collision.

           CONFIG_SUNXI=y
           CONFIG_DM=y
           CONFIG_DM_I2C=y
           CONFIG_DM_I2C_COMPAT=y      

 

* I'm running ARMBIAN 5.98 stable Ubuntu 18.04 LTS 4.19.152-sunxi

 

Any Ideas, suggestions ?

Thanks,

Joseph

Edited by J.M.
Add my SW version
Link to post
Share on other sites
Donate and support the project!

On 11/29/2020 at 4:22 PM, martinayotte said:

Did you added also CONFIG_CMD_I2C=y to recompile U-Boot with I2C related commands ?

Yes I did, but the compilation still fail. I guess I'm using the wrong configuration.

However, when I add CONFIG_SPL_DM=y, the compilation seems to work but later fails on:

u-boot-spl section `.data' will not fit in region `.sram'
region `.sram' overflowed by 820 bytes

 

Maybe I should try a different approach.

I've noticed that if I run "dm tree", I don't see the I2C in the device tree,

but if I call "i2c bus", I get:

Bus 0:  twsi0
and if I call "i2c dev 0", I get: 

Setting bus to 0
Valid chip addresses: 34

 

However, when I call "i2c dev 1" (or 2, or 3...), I get:

Invalid bus 1

i2c - I2C sub-system
 

Something here is weird. I don't see I2C0 (or any other I2C bus) at the device tree, but I do see it with the command "i2c dev 0".

So why is that I can't see the other bus (1, 2 or 3) with "i2c dev" command ?

Link to post
Share on other sites
On 11/30/2020 at 4:19 AM, sfx2000 said:

 

Light up a single bus - if you're looking for device detect - otherwise don't do this, and let the kernel sort it once booted with device tree...

 

What problem are you trying to solve?

I need to use an external LED device (not the LEDs that are on the board), and I need to be able control this device both from boot and linux (and in order to control this device I'm must enable the i2c3 bus).

The weird thing is that at the boot stage I do have access to i2c0 bus (which is used to control the AXP209), although I can't see it the device tree with "dm tree" (however i2c0 and i2c3 are defined in "sun7i-a20-lamobo-r1.dts").

 

Any ideas how to enable the i2c3 bus ?

(I though about trying to do the same as implemented with i2c0 for the AXP209, but I still didn't figure it out)

Link to post
Share on other sites
22 hours ago, martinayotte said:

Be aware that U-Boot and Kernel don't use the same DT file, you need to verify the one used in U-Boot build ...

Yes, of course. My I've modified the DT file that is located here: ../../../armbian/cache/sources/u-boot/v2019.04/arch/arm/dts/sun7i-a20-lamobo-r1.dts

Anyway to verify the u-boot does use this DT file ?

Link to post
Share on other sites
8 hours ago, martinayotte said:

Stop U-Boot using <spacebar> during USB can, then do "printenv" command and check the value of "fdtfile"

Thanks!


I did it, and I see that: fdtfile=sun7i-a20-lamobo-r1.dtb
I've also validate it with ${fdtfile} and it prints sun7i-a20-lamobo-r1.dtb

I noticed that ${efi_fdtfile} prints nothing. Is that ok?
 

dm tree prints the following:

 Class     Index  Probed  Driver                Name
-----------------------------------------------------------
 root         0  [ + ]   root_driver           root_driver
 simple_bus   0  [ + ]   generic_simple_bus    |-- soc@1c00000
 phy          0  [ + ]   sun4i_usb_phy         |   |-- phy@1c13400
 usb          0  [ + ]   ehci_generic          |   |-- usb@1c14000
 usb_hub      0  [ + ]   usb_hub               |   |   `-- usb_hub
 usb          1  [ + ]   ohci_generic          |   |-- usb@1c14400
 usb_hub      1  [ + ]   usb_hub               |   |   `-- usb_hub
 usb          2  [ + ]   ehci_generic          |   |-- usb@1c1c000
 usb_hub      2  [ + ]   usb_hub               |   |   `-- usb_hub
 usb_dev_ge   0  [ + ]   usb_dev_generic_drv   |   |       `-- generic_bus_2_dev_2
 clk          0  [ + ]   sun4i_a10_ccu         |   |-- clock@1c20000
 reset        0  [ + ]   sunxi_reset           |   |   `-- reset
 gpio         0  [ + ]   gpio_sunxi            |   |-- pinctrl@1c20800
 gpio         1  [ + ]   gpio_sunxi            |   |   |-- PA
 gpio         2  [ + ]   gpio_sunxi            |   |   |-- PB
 gpio         3  [ + ]   gpio_sunxi            |   |   |-- PC
 gpio         4  [ + ]   gpio_sunxi            |   |   |-- PD
 gpio         5  [ + ]   gpio_sunxi            |   |   |-- PE
 gpio         6  [ + ]   gpio_sunxi            |   |   |-- PF
 gpio         7  [ + ]   gpio_sunxi            |   |   |-- PG
 gpio         8  [ + ]   gpio_sunxi            |   |   |-- PH
 gpio         9  [ + ]   gpio_sunxi            |   |   `-- PI
 serial       0  [ + ]   ns16550_serial        |   |-- serial@1c28000
 serial       1  [   ]   ns16550_serial        |   |-- serial@1c28c00
 serial       2  [   ]   ns16550_serial        |   |-- serial@1c29c00
 eth          0  [ + ]   eth_designware        |   `-- ethernet@1c50000
 clk          1  [ + ]   fixed_rate_clock      |-- clk@1c20050
 clk          2  [ + ]   fixed_rate_clock      |-- clk@0
 clk          3  [   ]   fixed_rate_clock      |-- clk@1
 clk          4  [   ]   fixed_rate_clock      `-- clk@2

 

I  don't see any i2c bus in here.

However i2c bus give: 

Bus 0:  twsi0

 

Is that make sense?

 

Link to post
Share on other sites
14 hours ago, J.M. said:

I  don't see any i2c bus in here.

Did you checked all the possible configs in your cache/source/u-boot/v2019.04/.config

 

By default, "grep -i i2c" is showing :

 

# CONFIG_I2C0_ENABLE is not set
# CONFIG_I2C1_ENABLE is not set
# CONFIG_I2C2_ENABLE is not set
# CONFIG_SPL_I2C_SUPPORT is not set
# CONFIG_CMD_I2C is not set
# I2C support
# CONFIG_DM_I2C is not set
# CONFIG_SYS_I2C_DW is not set
# CONFIG_SYS_I2C_IMX_LPI2C is not set
# CONFIG_SYS_I2C_MXC is not set
# CONFIG_I2C_EDID is not set

 

Link to post
Share on other sites
On 12/4/2020 at 3:40 PM, martinayotte said:

Did you checked all the possible configs in your cache/source/u-boot/v2019.04/.config

 

By default, "grep -i i2c" is showing :

 


# CONFIG_I2C0_ENABLE is not set
# CONFIG_I2C1_ENABLE is not set
# CONFIG_I2C2_ENABLE is not set
# CONFIG_SPL_I2C_SUPPORT is not set
# CONFIG_CMD_I2C is not set
# I2C support
# CONFIG_DM_I2C is not set
# CONFIG_SYS_I2C_DW is not set
# CONFIG_SYS_I2C_IMX_LPI2C is not set
# CONFIG_SYS_I2C_MXC is not set
# CONFIG_I2C_EDID is not set

 

 

i did checked it,

and configs in your cache/source/u-boot/v2019.04/.config

and cache/sources/u-boot/v2019.04/arch/arm/dts/sun7i-a20-lamobo-r1.dts

seems to hold the same configuration...

 

Perhaps I'm not defining the device tree correct at u-boot ? (this is the same as I did to the device tree in linux - and in linux it work)

 

&i2c3 {
	pinctrl-names = "default";
	pinctrl-0 = <&i2c3_pins_a>;
	status = "okay";
};

 

jkjhk

Link to post
Share on other sites
23 hours ago, martinayotte said:

But the ".config" I've provided is "default = no i2c", you need to turn most of those to "=y" instead of "is not set" ...

First I must to correct my mistake:

I meant that cache/source/u-boot/v2019.04/configs/Lamobo_R1_defconfig and cache/source/u-boot/v2019.04/.config holds the same configuration.

(I was afraid that maybe my modifications on Lamobo_R1_defconfig doesn't set on .config)

 

In both Lamobo_R1_defconfig and .config these are my modifications, but the i2c still doesn't work (or presented on the device tree) on u-boot:

CONFIG_I2C0_ENABLE=y

CONFIG_I2C1_ENABLE=y

CONFIG_I2C2_ENABLE=y

CONFIG_I2C3_ENABLE=y

CONFIG_I2C4_ENABLE=y

CONFIG_DM=y
CONFIG_DM_I2C=y
CONFIG_DM_I2C_COMPAT=y

CONFIG_CMD_I2C=y   

 

I will keep digging, and share my results after solving the issue. I'm sure it will help to someone else in the future.

Ideas and suggestions are still very welcome (I'm sure it is possible. I'm not the first one that's trying it).

Thanks !!

Link to post
Share on other sites
  • Solution

After a short break I just want to update that I’ve managed to enable the i2c-3 on boot. The truth is that it was too simple… (later I’ll explain what was the mistake).

All I’ve needed to do is:

 

1.  Update the boot device tree (cache/sources/u-boot/v2019.04/arch/arm/dts/sun7i-a20-lamobo-r1.dts) with:

&i2c3 {
	pinctrl-names = "default";
	pinctrl-0 = <&i2c3_pins_a>;
	status = "okay";
};
  • I guess that instead of updating the boot device tree, I could also just update /boot/armbianEnv.txt with:
overlays=i2c3

 

2. Update Lamobo_R1_deconfig file with:

CONFIG_I2C0_ENABLE=y
CONFIG_I2C1_ENABLE=y
CONFIG_I2C2_ENABLE=y
CONFIG_I2C3_ENABLE=y
  • When I just added CONFIG_I2C3_ENABLE=y it didn’t work. I didn’t figure why...

The awkward reason I failed to do it in the beginning was because I’m using a script that updates my board on remote (without using SD card). But when I did the burning with SD - it worked !!

The difference between the remote burning script and the burning with SD script is that in the remote script I’m not burning all /dev/mmcblk1, but just /dev/mmcblk1p1 and /dev/mmcblk1p2.

And now I’m only guessing (so you are all welcome to correct my assumption), that the configuration of the i2c on boot is written into mmcblk1boot, and that is why it didn’t work when I used the remote burning script.

 

Thanks to all for the help and support.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...