On Tue, Apr 15, 2025 at 03:29:09PM +0530, Neha Malcom Francis wrote: > On 15/04/25 15:20, Miquel Raynal wrote: > >>> Francesco, are you also testing on K3 platforms? > >>> > >> > >> Yes he would be, since the firmware print is K3 firmware. > >> > >>> Can one of you boot with the patch below applied? It should partially > >>> revert the commit to the ancient behaviour, while adding more debug > >>> traces (please enable the debug logs as well). This should clarify > >>> which one of the 3 different path is likely failing. It should also help > >>> identify who's the user that fails to enable/disable its own power > >>> domain. I will need to know what board/SoC was used for the test, so I > >>> can look the relevant driver up. > >> > >> Booted on j784s4_evm > >> > >> https://gist.github.com/nehamalcom/b09687a523bec89f9df3537fdd99b6f3 > > ^ > >> > >> Currently debugging on my build where I hang in console_init itself, I > >> think the path for failure is different here, will confirm. > > > > Thanks a lot for your feedback. Normally by applying the diff shared in > > my previous e-mail, you should have the console back. If not, maybe > > there is something else involved and the blamed commit is just the first > > showing an underlying problem. > > I do have console back with that patch, see the gist link above. What I > meant was the path of failure seems to be different, it's looking like > with my version of firmware the serial driver probe > (ns16550_serial_probe) tries to do a readb() and fails, this could > possibly be because the device was not powered on to begin with. Whereas > in another case (what Francesco is seeing), this issue is not run into.
For the record, my logs and tests are on Verdin AM62 (that uses a TI AM625 SoC). Francesco
