[Letux-kernel] u-boot for e60k02

H. Nikolaus Schaller hns at goldelico.com
Sat Oct 5 08:27:50 CEST 2019 

Hi,

> Am 03.10.2019 um 19:30 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Thu, 3 Oct 2019 13:19:22 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> wait_for_sr_state: failed sr=81 cr=a0 state=2020
>> i2c_init_transfer: failed for chip 0x32 retry=0
>> wait_for_sr_state: failed sr=81 cr=a0 state=2020
>> i2c_init_transfer: failed for chip 0x32 retry=1
>> wait_for_sr_state: failed sr=81 cr=a0 state=2020
>> i2c_init_transfer: failed for chip 0x32 retry=2
>> i2c_init_transfer: give up i2c_regs=0x21a8000
>> RC5T619 write to [0xb7] 1 bytes failed !!
>> wait_for_sr_state: failed sr=81 cr=a0 state=2020
>> i2c_init_transfer: failed for chip 0x32 retry=0
>> wait_for_sr_state: failed sr=81 cr=a0 state=2020
>> i2c_init_transfer: failed for chip 0x32 retry=1
>> wait_for_sr_state: failed sr=81 cr=a0 state=2020
>> i2c_init_transfer: failed for chip 0x32 retry=2
>> i2c_init_transfer: give up i2c_regs=0x21a8000
>> RC5T619 read [0xb7] failed !!
>> REGISET2 val 9E

>> 
>> ^^^ the i2c issue seems to be the i2c where the RC5T619 is connected to.
>> 
> can you try out via cmdline whether other i2c devices are accessible,
> esp. backlight on i2c1?
> 
> Found something interesting in the i2c pinmux.
> IOMUX_CONFIG_SION = 0x10
> For some reason we do not have that is the kernel (and not in the
> kernel-imported pinmuxes used for i2c2 and i2c3):
> 
> ./arch/arm/include/asm/arch-mx6/mx6sll_pins.h:	MX6_PAD_I2C1_SCL__I2C1_SCL                            = IOMUX_PAD(0x0464, 0x019C, IOMUX_CONFIG_SION | 0, 0x067C, 0, 0),
> ./arch/arm/include/asm/arch-mx6/mx6sll_pins.h:	MX6_PAD_I2C1_SDA__I2C1_SDA                            = IOMUX_PAD(0x0468, 0x01A0, IOMUX_CONFIG_SION | 0, 0x0680, 0, 0),
> ./arch/arm/include/asm/arch-mx6/mx6sl_pins.h:	MX6_PAD_I2C1_SDA__I2C1_SDA				= IOMUX_PAD(0x0450, 0x0160, 0x10, 0x0720, 2, 0),
> ./arch/arm/include/asm/arch-mx6/mx6sl_pins.h:	MX6_PAD_I2C1_SCL__I2C1_SCL				= IOMUX_PAD(0x044C, 0x015C, 0x10, 0x071C, 2, 0),
> ./arch/arm/include/asm/arch-mx6/mx6sl-pins-kernel.h:MX6SL_PAD_I2C1_SCL__I2C1_SCL = IOMUX_PAD(0x44c,0x15c,0x0,0x71c,0x2,0),
> ./arch/arm/include/asm/arch-mx6/mx6sl-pins-kernel.h:MX6SL_PAD_I2C1_SDA__I2C1_SDA = IOMUX_PAD(0x450,0x160,0x0,0x720,0x2,0),
> 
> so maybe we just need to add that 0x10 to the I2C2 and I2C3 pinmuxes.

eBR-1A # i2c
i2c - I2C sub-system

Usage:
i2c bus [muxtype:muxaddr:muxchannel] - show I2C bus info
crc32 chip address[.0, .1, .2] count - compute CRC32 checksum
i2c dev [dev] - show or set current I2C bus
i2c loop chip address[.0, .1, .2] [# of objects] - looping read of device
i2c md chip address[.0, .1, .2] [# of objects] - read from I2C device
i2c mm chip address[.0, .1, .2] - write to I2C device (auto-incrementing)
i2c mw chip address[.0, .1, .2] value [count] - write to I2C device (fill)
i2c nm chip address[.0, .1, .2] - write to I2C device (constant address)
i2c probe [address] - test for and show device(s) on the I2C bus
i2c read chip address[.0, .1, .2] length memaddress - read to memory
i2c write memaddress chip address[.0, .1, .2] length [-s] - write memory
          to I2C; the -s option selects bulk write in a single transaction
i2c reset - re-init the I2C Controller
i2c speed [speed] - show or set I2C bus speed
eBR-1A # i2c dev
Current bus is 0
eBR-1A # i2c probe
Valid chip addresses: 36
eBR-1A # i2c dev 1
Setting bus to 1
eBR-1A # i2cprobe
Unknown command 'i2cprobe' - try 'help'
eBR-1A # i2c probe
Valid chip addresses:wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x0 retry=0
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x0 retry=1
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x0 retry=2
i2c_init_transfer: give up i2c_regs=0x21a4000
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x1 retry=0
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x1 retry=1
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x1 retry=2
...
i2c_init_transfer: failed for chip 0x7e retry=2
i2c_init_transfer: give up i2c_regs=0x21a4000
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x7f retry=0
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x7f retry=1
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x7f retry=2
i2c_init_transfer: give up i2c_regs=0x21a4000

eBR-1A # i2c dev 2
Setting bus to 2
eBR-1A # i2c probe 55
Valid chip addresses:wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x55 retry=0
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x55 retry=1
wait_for_sr_state: failed sr=81 cr=a0 state=2020
i2c_init_transfer: failed for chip 0x55 retry=2
i2c_init_transfer: give up i2c_regs=0x21a8000

eBR-1A # i2c dev 3
Invalid bus 3
i2c - I2C sub-system

Usage:
i2c bus [muxtype:muxaddr:muxchannel] - show I2C bus info
crc32 chip address[.0, .1, .2] count - compute CRC32 checksum
i2c dev [dev] - show or set current I2C bus
i2c loop chip address[.0, .1, .2] [# of objects] - looping read of device
i2c md chip address[.0, .1, .2] [# of objects] - read from I2C device
i2c mm chip address[.0, .1, .2] - write to I2C device (auto-incrementing)
i2c mw chip address[.0, .1, .2] value [count] - write to I2C device (fill)
i2c nm chip address[.0, .1, .2] - write to I2C device (constant address)
i2c probe [address] - test for and show device(s) on the I2C bus
i2c read chip address[.0, .1, .2] length memaddress - read to memory
i2c write memaddress chip address[.0, .1, .2] length [-s] - write memory
          to I2C; the -s option selects bulk write in a single transaction
i2c reset - re-init the I2C Controller
i2c speed [speed] - show or set I2C bus speed
eBR-1A # i2c dev 0
Setting bus to 0
eBR-1A # i2c probe 55
Valid chip addresses:
eBR-1A # 

So on which i2c bus should the RC5T619 respond?

>> 
>> ^^^ is this the same on Kobo?
>> 
> so I guess you have the tolino firstpart things and not the kobo ones.

Yes. Why is this important?

> Never seen this on kobo. I guess especially the hwcfg makes us enter
> rarely used codepaths it the patched kobo uboot.

What is hwcfg? Some config file read from the "firstpart" sectors
which influences what u-boot is doing? Sort of a proprietary boot.scr
mechanism?

>> 
>> Anyways we have made a big step forwards.
>> 
>> So the next steps are IMHO:
> retry with kobo firstpart (with m6sl uboot) to check whether things
> work.
> 
>> 1. fix the i2c issue on the Tolino - and potential other NTXGPIO setup issues
> 
> which might be fixed by that.

Hm. How should mmc contents (outside of u-boot code) influcence i2c pinmux setup?
Isn't that fully in our code?

> 
>> 2. get rid of the ntx special loader code that wants to see the 9 fastboot partitions
> 
> is probably also fixed by that (switch from android mode to ordinary
> linux by different hwcfg).
> Well, I think it is a good idea to be still able to boot the
> kobo kernel (or even convert the pinmuxes there to mx6sl). Or be able
> to copy code from there for first steps towards epdc, e.g. So
> I would not restructurize it too much in a first step.
> If we have a good kernel, then the time is there to do it.
> 
>> 3. make u-boot simply load uImage from /boot/uImage
> 
> well, maybe my bootchoice thing now works (which is included in the
> kobo-firstpart), would be interesting
> to verify. Then a /boot/boot.scr is loaded.

Ok. How is "bootchoice" operated? What does it do? Is it some new commands
in the u-boot environment?

> 
>> 4. make it load the device tree and set the address
> 
> load_ntxkernel
> run loadfdt
> setenv bootargs console=ttymxc0,115200 rootwait rw root=/dev/mmcblk0p5

Hm. I think I have no partition 5 with our current partitioning scheme.

> setenv fdtfile imx6sl-tolino-shine3.dtb
> load mmc 0:5 ${loadaddr} /boot/zImage
> load mmc 0:5 ${fdt_addr} /boot/dtb/${fdtfile} 
> bootz ${loadaddr} - ${fdt_addr}
> 
> Big attention: There is the quiet flag appended to cmdline in bootz.
> For my experiments I have first renamed it in the kernel in init/main.c:
> 
> early_param("quiet", quiet_kernel);
> But when you are already compiling uboot, you might remove the flag
> there, of course.

Yes, we should do... No hidden features :)

> I think before we tidy up uboot too much, maybe we should have a first
> look on the kernel, just to see if our assumptions about the hardware
> are correct without having mysterious, hacky uboot things influence our
> sight.

Well, that is why I would like to remove them first...

> The kobo/backlight branch on github.com/akemnade/linux.git might
> be the best thing now to try (not the mysterious 5.4-rc1).
> It includes a tolino dtb. Maybe enabling some CONFIG_REGULATOR_DEBUG
> might be interesting.
> 
> Anything influencing the boot process should imho go into a separate
> branch,

you mean in u-boot.git? Some e60k02-improved?

> so we can maybe be prepared for dualboot things. The
> kobolino uboot probably boots the android system also.

Now I am a little confused. What is the "kobolino uboot"?

BR and thanks,
Nikolaus

More information about the Letux-kernel mailing list