[Letux-kernel] 2016.11 uboot considered harmful

[Andreas Kemnade]

On Thu, 2 Feb 2017 07:59:01 +0100
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:

> Hi,
> 
> > Am 01.02.2017 um 22:57 schrieb Andreas Kemnade
> > <andreas at kemnade.info>:
> > 
> > Hi,
> > 
> > after some more clock hacking here is a short resume:
> > Starting with a correctly set clock (maybe using hwclock --systohc
> > from a running kernel) and then shutdown
> > 
> > you can read clock in uboot by
> > i2c dev 0
> > i2c mw 0x4b 0x29 0x41 1
> > i2c md 0x4b 0x1c 6
> > It will read out in bcd.
> > ss mm hh DD MM YY
> > 
> > If the values are sane and you boot the kernel, clock can be read
> > out correctly there.
> > 
> > Entering 2016.11 uboot gives a value
> >> 23 for hours (I have the suspicion it is a fixed offset.)
> > If you fix the hour value by hand
> > (i2c mw 0x4b 0x1e 0xXX 1
> >  i2c mw 0x4b 0x29 0x41 1)
> > the kernel will have the correct value.
> > 
> > If not, after some time in the boot process the clock will be set to
> > 2066.
> > 
> > Entering old uboot keeps the hours correctly.
> > -> kernel has also correct time
> > 
> > If you you enter poweroff at uboot cmdline,
> > and restart 2016.11 you will also have garbled hour value in the
> > rtc. So no kernel is needed to harm the clock.
> 
> Ok, that can help us to focus much more on the issues.
> 
> > 
> > having power loss for a short time does not influence anything.
> > 
> > I am very puzzled about this because I do not find twl rtc code in
> > the new uboot. So some register definitions might be mixed up. Any
> > hints?
> 
> Well, can you add some printf() to twl4030_i2c_write_u8 in
> include/twl4030.h? I hope that no code is directly writing.
> 
> Hm. I have another idea what it could be:
> 
> if the i2c bus is wrongly selected some driver for a different chip
> might write to the twl4030. That is because u-boot multi-i2c has to
> switch explicitly between busses and switch back. We do that for
> example in tsc2007_init through i2c_set_bus_num().
> 
> What I am not sure is if all our gta04 extensions properly switch
> back to the bus_num they found before. So running some of our
> extended commands (e.g. tsc2007) might address the wrong bus
> *afterwards*.
> 
> Now let's look into i2c slave address overlap.
> 
> RTC belongs to "Address Group—4b" in i2c1. Do we have and program a
> device at the same address on a different i2c bus? No :(
> 
what also might happen is that i2c-nak is mishandled and some data is
regarded as address by some chip.

> But we have an overlap at address 0x48 which might still make the
> tsc2007 driver change registers in the twl4030...
> 
> 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.
> 
probably print out the whole data. I will do that perhaps today evening.
lcm start
was not needed to achieve that data corruption.
So the amount of data should be overseeable.

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170202/fae8e02d/attachment.asc>