[Letux-kernel] 2016.11 uboot considered harmful

Dr. H. Nikolaus Schaller hns at goldelico.com
Thu Feb 2 19:27:03 CET 2017


Amorpher interesting question is if we still have to Enable Backup charging at all.
It might have been missing in 2011 uboot but fixed now.

On the Road --- hns

Am 02.02.2017 um 19:15 schrieb "H. Nikolaus Schaller" <hns at goldelico.com>:

> 
>> 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
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel


More information about the Letux-kernel mailing list