On 09/27/2017 04:03 AM, Joakim Tjernlund wrote: > On Mon, 2017-09-25 at 17:26 +0000, York Sun wrote: >> On 09/25/2017 09:55 AM, Joakim Tjernlund wrote: >>> We got some "broken" boards(mpx8321) where UART RX is held low(BREAK) >>> There we get a few: >>> serial8250: too much work for irq18 >>> and the board freezes. >>> >>> Looking inte to driver/CPU there is an errtum(A-004737) w.r.t BREAK handling >>> and I can see we are hitting the irq function fsl8250_handle_irq() added >>> in commit: 9deaa53ac7fa373623123aa4f18828dd62292b1a >>> "serial: add irq handler for Freescale 16550 errata." >>> For all I can tell this workaround is broken and I cannot figure out why. >>> Any pointers? >>> >> >> Jocke, >> >> Did you mean MPC8321? >> >> I personally don't have experience debugging this erratum. Have you >> tried to contact the patch author Paul Gortmaker to see how he managed >> to get it work? > > No, but I just found out it is u-boot related. If I use an very old u-boot it > works. > Between then and now we did a massive upgrade of u-boot and now if breaks. > And no, > bisect not possible due to local u-boot mods :)
How old? It is a good sign that an old U-Boot works. Git bisect would be a good tool if practical. Sometimes I have to reapply some local changes for every step of bisect to make it useful. You mileage may vary though. > > Any idea what could be different? I cannot see and I have tested > what I could see/think of but now I am out of ideas. I don't believe we have much change for MPC8321 for a long time. If any change has impact on kernel but not U-Boot itself, it may be other errata workarounds. I presume this happens on your own board. If I am in your shoes, I would try to reduce the number of local commits and reapply them to various U-Boot tags to further narrow down the search scope. In the mean time, getting register dump to compare the good and bad may be another way to go. York
