Adding Hannes and Heiko to the loop, please look at this problem.
On Saturday 25 April 2020 14:11:32 Pali Rohár wrote:
On Saturday 25 April 2020 07:00:58 Adam Ford wrote:
On Sat, Apr 25, 2020 at 6:50 AM Pali Rohár pali@kernel.org wrote:
On Saturday 25 April 2020 06:36:58 Adam Ford wrote:
On Sat, Apr 25, 2020 at 5:42 AM Pali Rohár pali@kernel.org wrote:
On Thursday 02 April 2020 20:42:31 Pali Rohár wrote:
On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote: > Hi, > > On 01/04/2020 00:42, Pali Rohár wrote: > > On Wednesday 01 April 2020 00:35:07 Pali Rohár wrote: > >> This patch series contain fixes for Nokia RX-51 board (aka N900). > >> After these changes it is possible to run U-Boot in qemu emulator again. > >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without > >> problem. > > > > But on real Nokia N900 device is U-Boot crashing in reboot loop. > > > > I do not have serial console for Nokia N900 to debug this issue, but > > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is > > that there is no crash and even no error in qemu emulator so I cannot > > debug this issue. > > > > First problem is around /* reset lp5523 led */ code in rx51.c. On real > > N900 device it generates repeating messages: > > > > Check if pads/pull-ups of bus are properly configured > > Timed out in wait_for_event: status=0000 > > > > When I commented that few lines all these messages disappeared. So > > problem is with OMAP I2C.
...
> > I remember that somebody had serial jig for Nokia N900, could somebody > > look at this reboot loop problem? > > > > And any idea how should be OMAP I2C configured in U-Boot to correctly > > work? > > > > Maybe I will try to find some time to git bisect which change broke > > U-Boot on real N900 hardware. > > Took latest u-boot master, applied patches and this is the result on > serial (first part is NOLO booting, I think that can be ignored) [1].
...
> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200) > > OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz > Nokia RX-51 + LPDDR/OneNAND > I2C: ready > DRAM: 256 MiB > NAND: 0 Bytes
Looks like that something with NAND is broken.
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > In: vga > Out: vga > Err: vga > Timed out in wait_for_event: status=0100 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > Timed out in wait_for_event: status=0000 > Check if pads/pull-ups of bus are properly configured > i2c_read (addr phase): pads on bus probably not configured (status=0x10) > i2c_write: timed out writig last byte!
These i2c errors are caused by
/* reset lp5523 led */ i2c_set_bus_num(1); state = 0xff; i2c_write(0x32, 0x3d, 1, &state, 1); i2c_set_bus_num(0);Is there anything which needs to be done to initialize i2c bus 1? Because this code is working fine on older U-Boot version.
Above code worked fine for U-Boot 2013.04, but in git version from January 2015 it prints above error messages.
On on internet forums I see these error messages also from other OMAP3 board, e.g. beagle board.
Has somebody some working OMAP3 board? And can test if it works with recent version of U-Boot? I guess that above i2c problem would happen also on other OMAP3 boards.
There was a conversion a while ago to dm_i2c, and I converted my board to support using the device tree during the SPL phase, and whenever I am aware any driver has driver model (DM) support, I try to convert my board.
I have a DM3730 and the last check I did was 2020.04-rc1, and it was working
Ok, so it either OMAP3430 specific problem or N900 board specific problem. N900 does not use driver model.
i have an OMAP3530 which is basically a 3430, and it works too. I am guessing the issue is unique to the N900 or the fact that it's high-security. Neither of my boards are HS parts. They are both GP.
N900 is HS device, but I guess that should be caused by GP vs HS difference. Working i2c bus 0 and non-working i2c bus 1 could not be caused by GP vs HS difference. Also I guess that omap hs mmc would be same on GP and HS boards.
...
Before calling i2c_write(0x32, ...) I tried to call i2c_probe(0x32) and it returned error.
If I tried to call "i2c dev 1" in U-Boot console, I got tons of errors and basically U-Boot stopped responding.
So by above observation it looks like I2C bus num 1 does not work, but I2C bus num 0 works fine.
Do I need to call i2c_probe(...) before calling i2c_write(...)?
And is something special needed for initializing omap i2c bus num 1? Because from my above observation it looks like that something is missing for bus 1 which in older u-boot version was not needed.
Now I was able to find commit which is causing above i2c problems: "Check if pads/pull-ups of bus are properly configured"
It is d5243359e1afc957acd373dbbde1cf6c70ee5485:
OMAP24xx I2C: Add support for set-speed
Adds support for set-speed on the OMAP24xx I2C Adapter.
Changes to omap24_i2c_write(...) for polling ARDY Bit from IRQ-Status. Otherwise on a subsequent call the transfer of last byte from the predecessor is aborted and therefore lost. For exmaple when i2c_write(...) is followed by a i2c_setspeed(...) (which has to deactivate and activate master for changing psc,...).
Minor cosmetical changes.
Signed-off-by: Hannes Petermaier oe5hpm@oevsv.at Cc: Heiko Schocher hs@denx.de
U-Boot version prior this command does not report those i2c errors.
Hannes, any idea how your patch could broke omap i2c i2c bus num 1 on Nokia N900?