[U-Boot] imx27lite stability problems.
I have tried u-boot for the imx27lite board from LogicPD which is currently in u-boot-arm repository and I have experienced some stability problems: - Sometimes the system gets stuck in serial_getc() from serial_mxc.c driver when printing information (ex. mii read ). - Pings do not work properly, the system gets stuck in fec_send() function waiting always for a frame to be sent (which actually does not happen). - Sometimes the system gets stuck when saving the environment to flash 'saveenv', but other times it does it well.
I would like to help to solve this problems, but I don't know exactly where to begin from. I have been reviewing clock settings. Could this be happening because this board is using 32KHz xtal as reference instead of 26MHz one?
Have you experienced these problems also?
Thank you.
Dear javier Martin,
In message eedb5540909170031k7b9076eeo8d4f60c799f1a27c@mail.gmail.com you wrote:
I have tried u-boot for the imx27lite board from LogicPD which is currently in u-boot-arm repository and I have experienced some stability problems:
- Sometimes the system gets stuck in serial_getc() from serial_mxc.c
driver when printing information (ex. mii read ).
- Pings do not work properly, the system gets stuck in fec_send()
function waiting always for a frame to be sent (which actually does not happen).
- Sometimes the system gets stuck when saving the environment to flash
'saveenv', but other times it does it well.
We don't see any such issues on the board we have here in the lab.
I would like to help to solve this problems, but I don't know exactly where to begin from. I have been reviewing clock settings. Could this be happening because this board is using 32KHz xtal as reference instead of 26MHz one?
Yes, of course this could be a problem. Is this an original LogicPD board? Did you adapt the code for the different clock speed? What exactly did you change?
Have you experienced these problems also?
No, we didn't.
Best regards,
Wolfgang Denk
2009/9/17 Wolfgang Denk wd@denx.de:
Dear javier Martin,
In message eedb5540909170031k7b9076eeo8d4f60c799f1a27c@mail.gmail.com you wrote:
I have tried u-boot for the imx27lite board from LogicPD which is currently in u-boot-arm repository and I have experienced some stability problems:
- Sometimes the system gets stuck in serial_getc() from serial_mxc.c
driver when printing information (ex. mii read ).
- Pings do not work properly, the system gets stuck in fec_send()
function waiting always for a frame to be sent (which actually does not happen).
- Sometimes the system gets stuck when saving the environment to flash
'saveenv', but other times it does it well.
We don't see any such issues on the board we have here in the lab.
I would like to help to solve this problems, but I don't know exactly where to begin from. I have been reviewing clock settings. Could this be happening because this board is using 32KHz xtal as reference instead of 26MHz one?
Yes, of course this could be a problem. Is this an original LogicPD board? Did you adapt the code for the different clock speed? What exactly did you change?
Sorry, I am not trying it on an original LogicPD board. Our board is based in i.mx27 ipcam. We have a different phy which is in 0x0 address instead of 0x1F and we have also a different NOR flash model. We have also the external 32KHz xtal at 32.768 KHz.
- The init code for our sdram is different as we have different model and memory configuration, however I made a memory test and all seems fine. - I adapted NOR flash configuration and PHY_ADDRESS only, and experienced the previous problems. I could expect issues with NOR flash but I don't know why I could have any issue with ethernet.
Have you experienced these problems also?
No, we didn't.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Monday is an awful way to spend one seventh of your life.
I've found some problems because the cache is enabled, I don't see any place where you disable it.
Are you sure you have this controlled properly?
Dear Javier Martin:
2009/9/17, javier Martin javier.martin@vista-silicon.com:
I've found some problems because the cache is enabled, I don't see any place where you disable it. [Fred] Do you means D-cache is enabled? There are no mmu enabled, D-cache should be disabled as default setting.
IAre you sure you have this controlled properly?
-- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
2009/9/17 Fred Fan fanyefeng@gmail.com:
Dear Javier Martin:
2009/9/17, javier Martin javier.martin@vista-silicon.com:
I've found some problems because the cache is enabled, I don't see any place where you disable it. [Fred] Do you means D-cache is enabled? There are no mmu enabled, D-cache should be disabled as default setting.
This is what I also though but I found it making some debugging through JTAG + GDB.
As I stated in my first mail, FEC driver was getting stuck after transmitting a frame in a while() loop. However, using wireshark the frame had actually been sent. And using GDB I found that in the SDRAM the while() condition was true, nevertheless the microprocessor was evaluating it as false. That seemed to cache issues to me, so I put a "dcache_disable()" just before that while() loop and saw that these problems were not happening anymore.
What is your opinion? Thanks.
2009/9/17 Wolfgang Denk wd@denx.de:
Dear javier Martin
I would like to help to solve this problems, but I don't know exactly where to begin from. I have been reviewing clock settings. Could this be happening because this board is using 32KHz xtal as reference instead of 26MHz one?
Yes, of course this could be a problem. Is this an original LogicPD board? Did you adapt the code for the different clock speed? What exactly did you change?
Dear Wolfgang Denk, I could finally test this in an original LogicPD i.mx27 litekit board and found the same problems. System gets stuck when issuing a ping command.
- I am using u-boot-arm repository "commit 617da90c1dcf65428ddfb63fef897439950bc915" without any modifications. - arm-linux-gcc toolchains from eldk-arm-4.1. - I configured u-boot for i.mx27 litekit, compiled and flashed it in the NOR with a JTAG.
Please, do you have an idea of what could I be missing?
Dear Javier Martin,
In message eedb5540910160633o81b1ae3sf37b2a00a5474584@mail.gmail.com you wrote:
I could finally test this in an original LogicPD i.mx27 litekit board and found the same problems. System gets stuck when issuing a ping command.
- I am using u-boot-arm repository "commit
617da90c1dcf65428ddfb63fef897439950bc915" without any modifications.
Can you please use mainline, i. e. the master branch at git://git.denx.de/u-boot.git instead?
Please, do you have an idea of what could I be missing?
Well, there is a "Possible iMX27 intermittent Ethernet connection issue rework" issued by LPD on 7/8/2008; in essence the PHY's internal 1.8V core regulator may shut off at power up.
To work around this, try and implement the following two hardware modifications:
1) Populate R841 with a 4.7K resistor. (This forces the internal core regulator off for the LAN8700. R841 is located on top of the PCB just "above" the LAN8700 IC.
2) Add a jumper wire from U125.5 to C561.1. This connects the on board 1.8V rail to the core ensuring that it is always powered.
And no, I don't guarantee you for anything.
Best regards,
Wolfgang Denk
2009/10/16 Wolfgang Denk wd@denx.de:
Dear Javier Martin,
In message eedb5540910160633o81b1ae3sf37b2a00a5474584@mail.gmail.com you wrote:
I could finally test this in an original LogicPD i.mx27 litekit board and found the same problems. System gets stuck when issuing a ping command.
- I am using u-boot-arm repository "commit
617da90c1dcf65428ddfb63fef897439950bc915" without any modifications.
Can you please use mainline, i. e. the master branch at git://git.denx.de/u-boot.git instead?
Please, do you have an idea of what could I be missing?
Well, there is a "Possible iMX27 intermittent Ethernet connection issue rework" issued by LPD on 7/8/2008; in essence the PHY's internal 1.8V core regulator may shut off at power up.
To work around this, try and implement the following two hardware modifications:
- Populate R841 with a 4.7K resistor. (This forces the internal core
regulator off for the LAN8700. R841 is located on top of the PCB just "above" the LAN8700 IC.
- Add a jumper wire from U125.5 to C561.1. This connects the on
board 1.8V rail to the core ensuring that it is always powered.
Before trying hardware fixes you suggested I tried using another toolchain which comes with LTIB for i.mx27ads:
* I used arm-linux-gnueabi- toolchain from LTIB with the command:
USE_PRIVATE_LIBGCC=yes make CROSS_COMPILE=arm-none-linux-gnueabi-
And found some improvements, ping doesn't hang the system, although it fails, but the second time it is executed I get an error:
=> ping 192.168.0.40 FEC_MXC: Autonegotiation timeout Using FEC_MXC device ping failed; host 192.168.0.40 is not alive
=> ping 192.168.0.40
Unhandled Exception: exception mode: abort fsr: 0x00000008 far: 0x0000000c
**UNRECOVERABLE ERROR** There was a memory access exception at 0x0000000c of type 'extern fetch1' this may be due to an access to an invalid memory region, unaligned access, or a problem with the current memory map. Please check the memory layout section of your processor manual. For information about the active memory map type 'info cpu'.
r00: a7e9c000 r01: 00000000 r02: 00000000 r03: 00000000 r04: a7e816f8 r05: a7e81700 r06: 00000000 r07: a7f31600 r08: a7e6ffe0 r09: 00000000 r10: 00000000 r11: 00000000 r12: a7f326f0 sp: a7e6f270 lr: 0001a908 pc: a7f1774c spsr:000000d3 cpsr:000000d7 bt: sp: a7e6f1a8 (stack: a00667e4 - a00697e4) (fp:00000000->a7e6f1d0, sp:a7e6f1a8)
What toolchain are you using for compiling this? It seems I got a different behavior changing it.
Dear Javier Martin,
In message eedb5540910190020t37a29377mdd5d56a6f33679af@mail.gmail.com you wrote:
Before trying hardware fixes you suggested I tried using another toolchain which comes with LTIB for i.mx27ads:
You may want to contact LPD support; eventually they replace your board with a working one.
- I used arm-linux-gnueabi- toolchain from LTIB with the command:
...
And found some improvements, ping doesn't hang the system, although it fails, but the second time it is executed I get an error:
...
What toolchain are you using for compiling this? It seems I got a different behavior changing it.
We are using ELDK.
Your test may indicate another issue (with the tool chain). Note that we saw different manifestations of this problem: some boards worked perfectly fine (no error ever), others failed always, one was workign or failing depending on temperature, phase of moon and other unknown factors.
Best regards,
Wolfgang Denk
participants (3)
-
Fred Fan -
javier Martin -
Wolfgang Denk