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?
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.
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).
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.
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?
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).
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?
Thank you.
When I have got a VIM2 device I had 2 issues:
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)
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.
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