[Letux-kernel] u-boot for e60k02
Andreas Kemnade
andreas at kemnade.info
Sat Oct 5 09:48:48 CEST 2019
On Sat, 5 Oct 2019 08:27:50 +0200
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 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
so i2c bus 0 = i2c1 seems to work (it has that 0x10 flag in pinmuxes
which only seems to exist in uboot but not in the kernel or set
separatetly somewhere.
> 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
and on this bus it should appear at address 32. But here we do not have
that
0x10 flag.
> 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?
>
&i2c3 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
ricoh619: pmic at 32 {
compatible = "ricoh,rc5t619";
in kernel. So I guess it is bus 2 (numbering starts from 0) in uboot.
> >>
> >> ^^^ 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?
>
mixture of that and something like a "device tree". Used by both
bootloader and vendor kernel.
> >>
> >> 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?
>
After further thinking I guess it should not influence i2c.
I think it is that 0x10 flag.
> >
> >> 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?
>
yes, some new commands, I am basically using the power key for input
and the led for output to implement a boot choice. See
https://misc.andi.de1.cc/kobo
> >
> >> 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.
>
well, correct that was just some c&p from my setup. It is:
keeping the original three partitions (main, rescue and fat-data) and
adding linux stuff behind it. So you can safely change that to
partition 1.
> > 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 :)
>
well, yes, that took quite a while until I understood. Normally the
rc5t619 code is noisy enough, so you see something. But on mainline
without that code...
Well, your situation is a bit different. I have a uboot which does what
it should do. And I have the original system there. So I did not want to
interfere with it too much.
No idea if more noisyness disturbs e.g. suspend on vendor kernel.
> > 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...
>
Well, if we get the kernel somehow booted, we can study hw behavior
from there and can easier ask things.
> > 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?
>
Maybe you have not noticed it yet.
The original kernel gets several additional address parameters via
cmdline where it can find the additional blobs. So if we change the boot
process, there are good chances that we disturb booting the original system.
So we basically close the doors for contributors who want to have a dual-boot
setup if we simply mix those things together.
> > 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"?
>
well I just mean the letux-uboot 60k02 branch.
Regards,
Andreas
More information about the Letux-kernel
mailing list