KBI does not work correctly on VIM2.V12 with Linux images, but works with Android (I2C device 0x18 errors)

VIM2
#1

Hello.

I have VIM2 v1.2 with 3GB RAM and 64GB eMMC.

When I’m trying to run any KBI-related command in U-Boot CLI I get “Error reading the chip: -110” error.

Also, some OS images (like VIM2_Ubuntu-minimal-focal_Linux-4.9_arm64_EMMC_V0.9.6-201117) with U-Boot 2015.01 installed using krescue leads to very slow U-Boot startup with following errors (part of boot log):
Product checking: pass! Hardware version: VIM2.V12

[aml_i2c_xfer] error ret = -110 i2c master a current slave addr is 0x18
i2c_read: i2c transfer failed
Error reading the chip: -110

I’m think this may be related to above errors returned by kbi-related commands.

Some other images (like VIM2_Debian-server-buster_Linux-5.9-rc2_arm64_SD-USB_V0.9.3-200907) with U-Boot 2020.04 does not have such slow U-Boot boot problem.

Is something wrong with my VIM2.V12 board, or KBI just does not exist on this board?

Thank you.

#2

Yep, KBI works for both V12 and V14 revisions.

Which command you run on the u-boot CLI? And please capture full output of the performing the command on the USB Serial and paste here? It will be helpful for us to figure out the issue.

Good day!

#3

I tried following commands:

kbi version
kbi usid
kbi bootmode r

All those commands freezes U-Boot for several seconds with one or more errors:

[aml_i2c_xfer] error ret = -110 i2c master a current slave addr is 0x18
i2c_read: i2c transfer failed
Error reading the chip: -110

Full log is available here

#4

Hello @S-trace

We will check on our side and feedback here.

#5

Hello @S-trace

We checked on our side, the kbi works well.

Have you checked some android images?

1 Like
#6

Hello @numbqq

I have installed VIM2.Android.Pie_V200624.emmc.kresq image and it had the same issue on first boot after installing, but after running i2c probe command (which hanged up) and then power cycling the board KBI commands started to work fine.

Then I have installed VIM2_Ubuntu-minimal-focal_Linux-4.9_arm64_EMMC_V0.9.6-201117.raw.img.xz again and KBI commands stopped working with same [aml_i2c_xfer] error ret = -110 i2c master a current slave addr is 0x18 error.

Then I have installed VIM2.Android.Pie_V200624.emmc.kresq again, and got the same results: first boot had [aml_i2c_xfer] error ret = -110 errors, but after booting Android once and power cycling the board those errors have vanished, KBI started to work fine and i2c probe U-Boot’s command started to work without hangups.

So, it seems my VIM2.V12 has a problem with i2c device 0x18, which does not respond with some U-Boot versions (like Ubuntu Focal’s U-Boot), but works with some other U-Boots (like Android Pie’s U-Boot).

Which chip has this address? EEPROM?

Thank you.

#7

I have tried to replace the Ubuntu Focal’s U-Boot with Android Pie’s U-Boot and it confirmed that my KBI/I2C problem is definitely related to U-Boot version.
With Pie’s U-Boot (U-Boot 2015.01-gdf4c3cf (Jun 24 2020 - 15:58:43)) KBI-related commands work fine, and with Focal’s U-Boot (U-Boot 2015.01 (Nov 17 2020 - 14:53:18)) KBI commands failing with error -110.

Unfortunately, git can’t show gdf4c3cf commit in https://github.com/khadas/u-boot repository.

Also, I didn’t figured out yet why I2C bus 0 fails with Focal’s U-Boot and works with Pie’s U-Boot, but Focal’s U-Boot definitely confuses the I2C bus 0 devices so badly that even board reset doesn’t recover them, and only complete power cycle can get devices on I2C bus 0 back to live even with correct U-Boot.

Could you please help me with debugging this issue (which U-Boot branch and configuration should I use to rebuild both U-Boot versions (Focal’s and Pie’s) and which commits should I checkout for both of those versions)?

I have found this forum topic which says that reducing SPI bus speed helps to avoid this problem, and it seems to be possible solution (khadas-vims-v2015.01 branch uses AML_I2C_SPPED_400K and works badly, but khadas-vims-pie uses AML_I2C_SPPED_100K and works fine).

Could you please check this and give me advices how can I debug this?

Thank you.

#8

Hello @S-trace

Could you please try to reinstall the ubuntu image and update the u-boot to a new version to check this issue?

Steps:

$ wget https://dl.khadas.com/test/linux-u-boot-vim2-vendor_0.9.7-2015.01_arm64.deb
$ sudo dpkg -i linux-u-boot-vim2-vendor_0.9.7-2015.01_arm64.deb
$ sync
$ sudo reboot

After reboot, please check the kbi again.

1 Like
#9

@numbqq Thank you, KBI works fine on the testing U-Boot version (after the board was power cycled).

But it still fails after Ubuntu Focal was booted using it and then rebooted.

I tried to underclock i2c@87c0 using following command:

fdtput /boot/dtb/kvim2_linux.dtb /soc/cbus@c1100000/i2c@87c0 clock-frequency 100000

And after the power cycle, the I2C bus started to work fine across Ubuntu’s reboots.
So, it seems Ubuntu’s DTB is broken too.

1 Like
#10

Thanks for your feedback. I will fix this.

3 Likes
#11

@numbqq Thank you too.

One interesting fact I noticed diagnosing this problem:
When i2c@87c0 bus is in a bad state - i2cdetect takes a long time to scan it, and gives the very strange result:

root@Khadas:~# i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
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:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- 16 -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3e --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- 59 -- -- -- -- -- --
60: -- -- -- -- -- -- -- 67 -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

This very differs from correct output (like here).

#12

t seems Krescue’s DTB should also be fixed (it’s uses 400KHz frequency too right now).
I fixed it using following commands:

mkdir /tmp/kresq/
mount /dev/mmcblk1p1 /tmp/kresq/
fdtput /tmp/kresq/rescue/fdt.kresq/amlogic/meson-gxm-khadas-vim2.dtb /soc/bus@c1100000/i2c@87c0 clock-frequency 100000
#13

Hello @hyphop

Please check on VIM2 krescue.

#14

Please check on VIM2 krescue.

all works

# Krescue
     __ _____  Khadas ## hyphop ## 
    / //_/ _ \___ ___ ______ _____ 
   / ,< / , _/ -_|_-</ __/ // / -_)
  /_/|_/_/|_|\__/___/\__/\_,_/\__/ 
                                   
 extreme tiny and fast rescue system

BUILD: 201125_300 from: Wed 25 Nov 2020 07:31:52 AM UTC

[i] POST_CONFIG:  booted=sd hwver=VIM2.V12
[w] root password undefined
[i] just type > krescue < to start gui
root@Krescue:/# kbi show
   VERSION: 0x0005
    DEVICE: 0x0000
 PORT_MODE: usb
 BOOT_MODE: mmc
        IR: on
       WOL: 0x02
       RTC: on
      DCIN: on

root@Krescue:/# i2c_status 
/sys/class/i2c-dev/i2c-0/dev:89:0
/sys/class/i2c-dev/i2c-0/name:Meson I2C adapter
/sys/class/i2c-dev/i2c-0/uevent:MAJOR=89
/sys/class/i2c-dev/i2c-0/uevent:MINOR=0
/sys/class/i2c-dev/i2c-0/uevent:DEVNAME=i2c-0
/sys/class/i2c-dev/i2c-1/dev:89:1
/sys/class/i2c-dev/i2c-1/name:Meson I2C adapter
/sys/class/i2c-dev/i2c-1/uevent:MAJOR=89
/sys/class/i2c-dev/i2c-1/uevent:MINOR=1
/sys/class/i2c-dev/i2c-1/uevent:DEVNAME=i2c-1
/sys/class/i2c-dev/i2c-2/dev:89:2
/sys/class/i2c-dev/i2c-2/name:DesignWare HDMI
/sys/class/i2c-dev/i2c-2/uevent:MAJOR=89
/sys/class/i2c-dev/i2c-2/uevent:MINOR=2
/sys/class/i2c-dev/i2c-2/uevent:DEVNAME=i2c-2
==fdt
/sys/firmware/devicetree/base/soc/bus@c1100000/i2c@8500/status:okay
/sys/firmware/devicetree/base/soc/bus@c1100000/i2c@87c0/status:okay
/sys/firmware/devicetree/base/soc/bus@c1100000/i2c@87e0/status:disabled
/sys/firmware/devicetree/base/soc/bus@c8100000/i2c@500/status:disabled
#15

same works in any case

U-Boot 2015.01 (Nov 17 2020 - 14:53:18)
DRAM:  3 GiB

kvim2#kbi hwver 
saradc: 0x202, hw_ver: 0x22 (VIM2.V12)

PS: look like your device defective and unstable !?

#16

Maybe.
It seems this defect is not very common (but I’ve found some mentions of this error in the forum).
However (excluding this I2C issue) board works fine in Ubuntu (I’m running it as a dual-band hotspot with PiHole and its uptime is 19.5 hours and keep growing).

May this I2C problem be related to PIC’s firmware version?

#17

we can change default i2c frequency to 100Khz from 400Khz

1 Like
#18

Thank you.
When I have got a VIM2 device I had 2 issues:

  1. I wasn’t able to install some of the images present in the Krescue’s list (this issue was already fixed by Krescue’s upgrade)
  2. Some images had this issue with the I2C 400KHz problem on my device (like a very slow boot problem), as discussed here.

Thank you for supporting old-generation boards - it’s very good for beginners who have just got the board and getting their first steps to developing things on those boards.

#19

need upgrade krescue every time its very easy - if you board have internet connection u can get notification if new krescue version exist ! just press OK

Some images had this issue with the I2C 400KHz problem on my device (like a very slow boot problem), as discussed here.

all vendor uboot or kernel images have 400KHz

all mainline uboot or kernel have 100Khz

PS: we will update vendor images for 100Khz soon

PSS: if krescue was started by tripple KEY_F will used 100Khz in any case

1 Like