[Letux-kernel] 2016.11 uboot considered harmful
andreas at kemnade.info
Thu Feb 2 12:35:42 CET 2017
On Thu, 2 Feb 2017 07:59:01 +0100
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> > 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
> 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.
was not needed to achieve that data corruption.
So the amount of data should be overseeable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Letux-kernel