[Letux-kernel] 2016.11 uboot considered harmful

[H. Nikolaus Schaller]

> Am 02.02.2017 um 18:50 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Thu, 2 Feb 2017 07:59:01 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> So it might be better to add a printf() to i2c_write and make it
>> print the bus_num, the chip address, and data length. Or we restrict
>> the printf to bus_num=i2c1. This might show something unexpected.
>> 
> U-Boot 2016.11-01291-g4dc3230-dirty (Feb 02 2017 - 18:43:34 +0100)
> 
> OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz
> GTA04 + LPDDR/NAND
> I2C:   ready
> DRAM:  512 MiB
> NAND:  512 MiB
> MMC:   OMAP SD/MMC: 0
> *** Warning - bad CRC, using default environment
> 
> ->i2c 0: chip: 4b addr: 79: 09
> ->i2c 0: chip: 4b addr: 76: 20
> ->i2c 0: chip: 4b addr: 7d: 02
> ->i2c 0: chip: 4b addr: 7a: 20
> ->i2c 1: chip: 45 addr: 00: 00
> ->i2c 1: chip: 45 addr: 01: 00
> ->i2c 1: chip: 45 addr: 02: 40
> ->i2c 0: chip: 4b addr: 7d: 03
> ->i2c 0: chip: 4b addr: 7a: 20
> ->i2c 0: chip: 4b addr: 91: 05
> ->i2c 0: chip: 4b addr: 8e: e0
> ->i2c 0: chip: 4b addr: 99: 03
> ->i2c 0: chip: 4b addr: 96: 20
> <-i2c 0: chip: 4b addr: 46: 40
> ->i2c 0: chip: 4b addr: 46: 40
> ->i2c 0: chip: 4b addr: 1e: 6d
>                        ^^
> RTC hour register. Now it is just about to find the bad line of code
> doing that.

Good experimental data!

It looks as if it comes after reading the environment and before
running boot.scr.

a) what comes next after this?
b) does u-boot have a dump_stack() function like Linux - probably not...
c) our gta04.c board file does some twl4030_pmrecv_vsel_cfg() to enable additional regulators. Maybe one goes wrong?

What could have happened is that although the code was copied from our 2011 u-boot
some address constants may now need an offset or whatever.

So let's augment the register numbers by their meaning

> ->i2c 0: chip: 4b addr: 79: 09 - VAUX2_DEDICATED
> ->i2c 0: chip: 4b addr: 76: 20 - VAUX2_DEVGRP
> ->i2c 0: chip: 4b addr: 7d: 02 - VAUX3_DEDICATED
> ->i2c 0: chip: 4b addr: 7a: 20 - VAUX3_DEVGRP
> ->i2c 1: chip: 45 addr: 00: 00
> ->i2c 1: chip: 45 addr: 01: 00
> ->i2c 1: chip: 45 addr: 02: 40
> ->i2c 0: chip: 4b addr: 7d: 03 - VAUX3_DEDICATED
> ->i2c 0: chip: 4b addr: 7a: 20 - VAUX3_DEVGRP
> ->i2c 0: chip: 4b addr: 91: 05 - VPLL2_DEDICATED
> ->i2c 0: chip: 4b addr: 8e: e0 - VPLL2_DEV_GRP
> ->i2c 0: chip: 4b addr: 99: 03 - VDAC_DEDICATED
> ->i2c 0: chip: 4b addr: 96: 20 - VDAC_DEV_GRP
> <-i2c 0: chip: 4b addr: 46: 40 - P1_SW_EVENTS
> ->i2c 0: chip: 4b addr: 46: 40 - P1_SW_EVENTS
> ->i2c 0: chip: 4b addr: 1e: 6d - HOURS_REG

Now if we look into our gta04.c, there is code to do such things.

misc_init_r() sets VAUX2 and vaux3 and there I even find the constants 0x09 and 0x02 :)
after this it calls tca6507_reset() and tps65950_init().
Next it should print the omap_die_id_display(). If this comes after this sequence I would
say the bug is in tps65950_init().

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170202/d349af1b/attachment.asc>